Qué información necesita una consultora para cotizar una implementación de IA
Conoce qué información necesita una consultora para cotizar una implementación de IA: proceso, datos, sistemas, usuarios, riesgos, alcance y métricas.

# ¿Por qué “queremos usar IA” no alcanza para cotizar?
La misma frase puede describir proyectos muy distintos:
- habilitar un espacio empresarial de Claude o ChatGPT para veinte personas;
- capacitar a un equipo para trabajar con documentos;
- crear un asistente que consulte políticas internas;
- analizar llamadas y registrar resultados en un CRM;
- extraer datos de expedientes y enviarlos a un ERP;
- construir un modelo predictivo con datos históricos;
- automatizar una parte de un proceso con aprobación humana.
Cada caso cambia la arquitectura, los permisos, el esfuerzo, los riesgos y el soporte. Una licencia puede activarse en días; una integración con sistemas heredados puede requerir acceso técnico, pruebas, seguridad y coordinación con varios proveedores.
Por eso una cotización seria no comienza con “¿cuántos usuarios son?”. Comienza con “¿qué decisión o tarea necesita mejorar y cómo se realiza hoy?”.
# Las nueve piezas de información que definen el alcance
| Área | Pregunta central | Efecto en la cotización |
|---|---|---|
| Resultado | ¿Qué debe cambiar y para quién? | Define prioridad y criterio de aceptación |
| Proceso actual | ¿Cómo se trabaja hoy? | Revela excepciones y tareas reales |
| Volumen | ¿Cuántos casos y con qué frecuencia? | Afecta capacidad, costos y operación |
| Datos | ¿Qué existe y con qué calidad? | Determina preparación, permisos y evaluación |
| Sistemas | ¿Dónde vive la información? | Define integraciones y dependencias |
| Usuarios | ¿Quién usa, revisa y administra? | Cambia licencias, UX, capacitación y soporte |
| Riesgo | ¿Qué pasa si la salida es incorrecta? | Determina controles y supervisión |
| Autonomía | ¿La IA propone o ejecuta? | Cambia complejidad, reversibilidad y gobierno |
| Éxito | ¿Cómo se comprobará el valor? | Define piloto, métricas y decisión de escalar |
# 1. Resultado esperado
Una frase útil describe el cambio observable. Por ejemplo: “reducir el tiempo para preparar el resumen de una llamada y mejorar la captura del siguiente paso, sin actualizar campos sensibles sin confirmación”.
No es necesario prometer un porcentaje antes de medir. Sí es necesario identificar al usuario, la tarea, la frecuencia y la decisión que se quiere mejorar.
# 2. Proceso actual
El proceso real rara vez coincide por completo con un diagrama. Conviene observar uno o dos casos de principio a fin y registrar entradas, responsables, herramientas, esperas, retrabajo y excepciones.
Preguntas útiles:
- ¿Qué dispara el proceso?
- ¿Quién recibe la solicitud?
- ¿Qué información consulta?
- ¿Qué decide y con qué autoridad?
- ¿Qué produce al final?
- ¿Dónde se registra?
- ¿Qué ocurre cuando falta información?
- ¿Qué casos salen del flujo normal?
Sin esta revisión, una propuesta puede automatizar un paso visible y dejar intacto el cuello de botella real.
# 3. Volumen y frecuencia
La consultora necesita rangos verificables: llamadas por semana, documentos por mes, páginas promedio, usuarios simultáneos, idiomas, horarios y crecimiento previsto.
El volumen afecta consumo de API, almacenamiento, colas, rendimiento y soporte. También puede revelar que el problema no necesita desarrollo: si hay pocos casos y alto juicio humano, una plataforma existente con un procedimiento claro podría ser suficiente.
# 4. Datos disponibles
No basta con saber que “hay una base”. Hay que revisar formato, calidad, cobertura, antigüedad, duplicados, campos vacíos, permisos y significado.
Para un piloto suelen necesitarse ejemplos representativos y autorizados. Una muestra debe incluir casos fáciles, difíciles, incompletos y excepcionales. Si solamente se muestran los mejores expedientes, la estimación será demasiado optimista.
También debe identificarse información personal, confidencial, financiera, legal, clínica o estratégica. Esa clasificación influye en el producto, contrato, infraestructura, retención y acceso.
# 5. Sistemas e integraciones
La diferencia entre “usar IA” e “integrar IA” suele estar aquí. Es necesario listar CRM, ERP, telefonía, almacenamiento documental, correo, autenticación y cualquier sistema de registro.
Por cada sistema conviene saber:
- quién lo administra;
- si tiene API y documentación vigente;
- qué permisos pueden otorgarse;
- si existe ambiente de pruebas;
- qué límites o costos impone;
- qué datos deben leerse o escribirse;
- cómo se revierte una acción incorrecta.
Una integración sin acceso confirmado sigue siendo una hipótesis, no un alcance cerrado.
# 6. Usuarios, roles y adopción
No todos necesitan el mismo acceso. Identifique usuarios finales, supervisores, administradores, seguridad, legal, TI y dueño del proceso. Defina quién puede consultar fuentes, aprobar una salida, modificar instrucciones, conectar datos y revisar registros.
La adopción también tiene costo. Incluye diseño de casos de uso, capacitación, materiales, soporte inicial y seguimiento. Comprar asientos sin preparar el trabajo puede producir mucha actividad y poco cambio operativo.
# 7. Riesgo y cumplimiento
La pregunta más útil es: ¿qué pasa si la salida es incorrecta, incompleta, tardía o visible para quien no corresponde?
La respuesta determina si basta una revisión ligera o se necesitan validaciones, doble aprobación, auditoría, aislamiento de datos y asesoría especializada. En medicina, derecho, finanzas, recursos humanos, seguridad o infraestructura, el umbral debe ser más alto.
El proveedor necesita conocer las políticas y obligaciones aplicables, pero no debe inventarlas. La organización conserva la responsabilidad de aprobar requisitos legales, de privacidad y sectoriales.
# 8. Nivel de autonomía
Hay una gran diferencia entre:
- buscar información;
- redactar una propuesta;
- recomendar una acción;
- preparar un cambio para aprobación;
- ejecutar automáticamente.
Cada nivel agrega controles. Una cotización debe decir qué acciones quedan dentro del alcance, cuáles necesitan revisión y cuáles están prohibidas. “Agente de IA” no es una especificación suficiente.
# 9. Métricas y aceptación
Antes de construir, las partes deben acordar cómo se decidirá si el piloto funcionó.
Las métricas pueden incluir tiempo por caso, precisión de extracción, correcciones, cobertura, adopción, costo por transacción y satisfacción. Para evaluar calidad se necesita un conjunto de casos y una referencia humana.
El criterio de aceptación debe incluir límites. Un sistema puede ahorrar tiempo y aun no ser apto para determinados documentos o decisiones.
# ¿Qué documentos aceleran una cotización?
No se necesita preparar un expediente perfecto. Estos elementos suelen ser suficientes para una primera estimación:
- descripción del objetivo en una página;
- diagrama simple del proceso actual;
- lista de sistemas y responsables;
- volúmenes aproximados con fuente y periodo;
- muestras anonimizadas o acceso controlado;
- roles de usuario y número de personas;
- políticas de seguridad y privacidad relevantes;
- restricciones de fecha, presupuesto o contratación;
- criterio de éxito y persona que aprobará el piloto.
Si algunos elementos no existen, el diagnóstico puede producirlos. Lo importante es señalar lo verificado, lo estimado y lo pendiente.
# ¿Qué partes debe separar la propuesta económica?
Una propuesta clara distingue costos de naturaleza diferente.
# Licencias y consumo
Incluye asientos de una plataforma, uso de API, almacenamiento u otros servicios de terceros. Los precios y condiciones pueden cambiar, por lo que deben fecharse y mostrar quién contrata y paga al proveedor.
# Diagnóstico y diseño
Comprende entrevistas, observación, inventario de datos, evaluación de riesgos, definición de caso de uso, arquitectura y plan de piloto. Es trabajo profesional aunque todavía no exista código.
# Configuración e implementación
Puede incluir espacios de trabajo, permisos, instrucciones, plantillas, conectores, desarrollo, pruebas, monitoreo y documentación.
# Capacitación y adopción
Debe especificar audiencia, duración, materiales, práctica con casos reales, soporte y medición. Una sesión genérica no sustituye la preparación del proceso.
# Operación y mejora
Incluye soporte, revisión de calidad, cambios, costos variables, evaluación periódica y respuesta a incidentes. También debe aclarar qué se considera mantenimiento y qué es un nuevo alcance.
# ¿Cuándo conviene una fase de diagnóstico pagada?
Conviene cuando existen varias áreas interesadas, no hay un proceso definido, los datos no han sido revisados, la integración depende de terceros o el riesgo de una mala decisión es relevante.
La fase debe tener duración y entregables concretos. Por ejemplo:
- mapa del proceso y responsables;
- inventario de datos y sistemas;
- priorización de casos de uso;
- riesgos y controles iniciales;
- alternativa de plataforma, API o enfoque híbrido;
- alcance y métricas del piloto;
- rango de inversión para la siguiente fase;
- recomendación de avanzar, preparar datos o detener.
Un diagnóstico no debería ser una consultoría indefinida. Su resultado es reducir incertidumbre suficiente para tomar una decisión.
# ¿Por qué algunas cotizaciones solo pueden ofrecer un rango?
Un rango es responsable cuando las variables principales están identificadas pero todavía no verificadas. Debe incluir supuestos y factores que lo pueden mover.
Ejemplo: la estimación supone una API documentada, un solo idioma, dos tipos de documento y revisión humana antes de escribir en el CRM. Si después aparecen diez formatos, un sistema sin API o la necesidad de operar en tiempo real, cambia el alcance.
Lo problemático no es el rango. Lo problemático es ocultar incertidumbre detrás de una cifra exacta.
# Señales de alerta en una cotización de IA
Revise con cuidado si la propuesta:
- empieza por la herramienta y no por el proceso;
- promete ahorros o ventas sin línea base;
- mezcla licencias con implementación;
- no identifica costos recurrentes;
- asume acceso a sistemas no verificado;
- no explica tratamiento de datos;
- no incluye evaluación con casos reales;
- no define revisión humana ni rollback;
- llama “piloto” a un desarrollo completo;
- no establece quién aprueba el resultado.
Una buena propuesta puede contener condiciones y preguntas pendientes. Eso es más honesto que fingir certeza.
# Plantilla breve para solicitar una cotización
Puede iniciar con este formato:
Objetivo: qué tarea o decisión se quiere mejorar. Usuarios: quiénes participan y cuántos son. Proceso actual: pasos, herramientas y excepciones. Volumen: casos por periodo, tamaño y horarios. Datos: fuentes, formatos, sensibilidad y calidad conocida. Sistemas: integraciones necesarias y responsables técnicos. Autonomía: qué puede proponer, aprobar o ejecutar la IA. Riesgos: consecuencias de una salida incorrecta. Éxito: métricas y persona que aceptará el piloto. Restricciones: plazo, presupuesto, contratación y políticas.
No hace falta responder todo para solicitar una conversación. Sí ayuda a identificar desde el inicio qué debe investigarse.
# Preguntas frecuentes
# ¿Se puede cotizar sin ver los datos?
Puede darse un rango condicionado o cotizar un diagnóstico. Un precio cerrado para implementación sin revisar ejemplos, permisos y calidad suele depender de supuestos que deben quedar explícitos.
# ¿La licencia de Claude o ChatGPT incluye la implementación?
No. Una licencia da acceso al producto y a sus funciones según el plan. El diseño de casos de uso, configuración, integración, políticas, capacitación, evaluación y soporte son actividades separadas.
# ¿Quién debe participar en la primera reunión?
El dueño del proceso y una persona que conozca la operación. Si habrá integración o datos sensibles, también TI, seguridad, privacidad o legal según corresponda. No es necesario reunir a toda la organización para definir la primera hipótesis.
# ¿Cuánto dura un diagnóstico?
Depende del número de procesos, sistemas y partes involucradas. Debe tener un alcance corto y entregables definidos. Su duración no debería presentarse como universal antes de conocer el contexto.
# ¿La consultora debe revender las licencias?
No necesariamente. La empresa puede contratar directamente al proveedor y contratar por separado diagnóstico, configuración, integración, gobierno y adopción. Esto también hace más clara la relación y evita presentar autorizaciones comerciales inexistentes.
# Conclusión
Una cotización de IA no debería valorar una idea abstracta. Debe valorar un cambio definido en un proceso, con datos, sistemas, personas, controles y una forma de comprobar resultados.
Cuando faltan elementos, el siguiente paso no es inflar el alcance ni prometer una cifra. Es reducir incertidumbre con un diagnóstico breve.
La conversación comercial mejora cuando ambas partes separan licencias, implementación, capacitación y operación. Así la empresa puede comparar alternativas y saber exactamente qué está comprando.
# Fuentes y referencias
- NIST AI RMF Core: gobernar, mapear, medir y gestionar
- NIST AI Risk Management Framework: Generative AI Profile
- Privacidad empresarial de OpenAI
- Retención de datos para productos comerciales de Anthropic
