Casi toda empresa mediana o grande de Brasil ya hizo su piloto de IA corporativa. Un asistente en la mesa de servicio, un resumen de contrato, un copiloto para el equipo de datos. La demostración impresiona, el patrocinador aplaude y, tres meses después, el proyecto está detenido. No porque el modelo fuera malo — los modelos son excelentes y mejoran solos. Se detuvo porque nadie diseñó la arquitectura a su alrededor.

En la práctica, el modelo es la pieza más barata y más reemplazable del conjunto. Lo caro es el resto: de dónde viene el contexto, quién puede ver qué, qué tiene permiso la IA de hacer sola y cómo usted demuestra que aquello dio retorno. Por eso, en este artículo tratamos la IA como un problema de ingeniería y de gobernanza — y usamos la propia operación de Inove como caso de estudio.

Por qué los pilotos de IA no llegan a producción

Cuando abrimos un piloto trabado, el diagnóstico suele caer en tres causas — y rara vez es la calidad del modelo.

Contexto pobre. El asistente responde bien sobre el mundo y mal sobre su empresa. Le falta el historial del cliente, el contrato vigente, el ticket de la semana pasada, la regla fiscal que solo existe en un anexo. Sin ese material, la IA es un pasante brillante en su primer día: rápido, educado y desinformado.

Dueño indefinido. El piloto nace en un área de negocio, corre en un SaaS pagado con la tarjeta de alguien y nunca entra en el ciclo de vida de TI. No tiene responsable de acceso, actualización ni incidentes. Cuando el entusiasta cambia de equipo, el proyecto muere de causas naturales.

ROI no medido. Nadie midió la línea de base antes. ¿Cuántos minutos tomaba atender un ticket? ¿Cuánto retrabajo por mes? Sin ese número previo, cualquier ganancia se vuelve opinión — y la opinión no sobrevive al recorte de presupuesto del trimestre siguiente.

Las capas: estructurado, no estructurado y memoria viva

El contexto no es un solo balde. Tiene tres capas, con costo, riesgo y ciclo de actualización distintos. Tratarlo todo igual es el error más común.

Los datos estructurados son los que ya viven en el ERP, en el CRM, en la base de datos, en la herramienta de tickets. Son confiables, versionados y tienen dueño. La IA no debe «aprender» esos datos: debe consultarlos en el momento, mediante una consulta parametrizada, y citar el origen. Aquí el patrón correcto es una herramienta, no texto.

Los datos no estructurados son el acervo real de la empresa: propuestas, actas, correos, documentación de proyecto, presentación de kickoff, informe técnico. Ahí está el conocimiento que nadie escribió en un campo de formulario — y ahí también vive el riesgo de fuga y de información desactualizada.

La memoria viva es la capa que casi todos olvidan. Es el resumen curado de lo que importa sobre un cliente, un ambiente, un proyecto: decisiones tomadas, restricciones conocidas, preferencias, pendientes. No es el documento entero; es la ficha destilada. Necesita fecha, fuente y vencimiento — la memoria sin validez envejece y miente con confianza.

RAG, MCP y agentes: cuándo usar cada uno

Existen tres patrones de arquitectura que resuelven problemas distintos. Elegir mal es lo que produce ese asistente caro que nadie usa.

RAG (buscar antes de responder). La IA busca fragmentos relevantes en su acervo y responde citando la fuente. Úselo cuando la pregunta es sobre conocimiento quieto: política interna, documentación, historial de proyecto, manual de proceso. Es el patrón más barato y el más fácil de auditar, porque toda respuesta apunta a un documento. No use RAG para números que cambian a cada hora — saldo, inventario, estado de un ticket. En ese caso devuelve la foto de ayer con cara de verdad de hoy.

MCP (la IA usa sus herramientas). Aquí usted no copia datos hacia dentro de la IA: expone una puerta estandarizada para que consulte el sistema en tiempo real, con la credencial correcta. Es el patrón para dato vivo y para operación — abrir un ticket, verificar el estado de un ambiente, leer un indicador. La ventaja de gobernanza es grande: el acceso sigue siendo del sistema de origen, con el mismo control de permisos que ya existe, y no de una copia paralela que nadie revoca.

Agentes con barandas de protección. Un agente encadena pasos: consulta, decide, ejecuta, verifica. Solo tiene sentido cuando el proceso es repetitivo, tiene regla clara y un costo de error que usted logra contener. Y «contener» tiene nombre técnico: alcance de credencial mínimo, ambiente separado, aprobación humana para cualquier paso irreversible y registro completo de cada acción. Sin eso, usted automatizó el error — que es exactamente lo que las buenas prácticas de ciberseguridad mandan evitar.

Gobernanza y protección de datos: personalización sin invasión

Personalizar la atención con IA es legítimo. Lo que separa personalización de invasión son tres decisiones escritas antes de la primera línea de código.

Finalidad. Cada dato en el contexto necesita responder «para qué». El registro técnico de un ambiente sirve para atender mejor ese ambiente — no para perfilar personas. Si usted no logra escribir la finalidad en una frase, ese dato no entra.

Retención. La memoria sin plazo se vuelve un pasivo. Defina cuánto tiempo vive cada tipo de registro y qué ocurre al final del contrato. Es la misma disciplina de descarte que aplicamos en la gestión de volumen de datos: guardar todo para siempre es caro y es riesgo.

Lo que nunca entra en el contexto. Credenciales, claves de API, datos personales sensibles, información de terceros sin base legal. Esa lista debe ser explícita y verificada por un filtro automático, no por la buena voluntad de quien escribe el prompt. Sume a eso lo básico de siempre: acceso por perfil, registro de quién consultó qué y revisión periódica de permisos.

El caso de la propia Inove

Aplicamos esto en nuestra operación de atención, y el diseño tiene cuatro etapas.

Primero, captura: todo lo que ocurre en una atención se convierte en registro — ticket, diagnóstico, decisión técnica, documentación de ambiente. Luego, memoria: en vez de apilar transcripciones, destilamos fichas por cliente y por ambiente, con fuente y fecha. En seguida, contexto: cuando un consultor abre un asunto, el material relevante se arma en el momento, filtrado por el permiso de esa persona. Por último, acción asistida: la IA prepara el borrador del informe, sugiere la causa raíz probable, arma el guion de verificación — y un especialista aprueba antes de que algo toque el ambiente del cliente.

La ganancia no es mágica, es acumulativa. El consultor que asume un ticket a las dos de la madrugada ya empieza sabiendo qué se intentó antes. Y, del lado del cliente, el efecto práctico es ser atendido por quien recuerda el contexto — sin que nadie tenga que repetir toda la historia de nuevo. Vale para el soporte de TI tanto como para un proyecto.

Adopción por olas y qué medir

Nunca empezamos por automatizar. El orden que funciona es: ola 1, la IA lee y resume (riesgo casi nulo, ganancia inmediata); ola 2, la IA consulta sistemas y responde con fuente; ola 3, la IA redacta borradores de entregables con revisión obligatoria; ola 4, un agente ejecuta tareas reversibles y bien delimitadas. Cada ola solo se abre cuando la anterior tiene un indicador estable.

Y mida cuatro cosas desde el día cero: el tiempo de ciclo de la tarea (con la línea de base anterior), la tasa de retrabajo en lo que la IA produjo, la cobertura de fuente — cuántas respuestas citan un origen verificable — y el costo por tarea, incluyendo el consumo de tokens. Este último exige una disciplina idéntica a la de FinOps: sin visibilidad de consumo por caso de uso, la cuenta crece sin que nadie sepa de dónde vino.

Para profundizar, vale combinar este material con los contenidos de Inove Academy — en especial el e-book de Ciberseguridad y protección de datos, que trata la gobernanza de acceso que sostiene cualquier proyecto de IA, y la calculadora FinOps, útil para modelar el costo recurrente antes de escalar.

Al final, la pregunta que separa el piloto de la producción no es «qué modelo usar». Es otra, bastante más aburrida y bastante más útil: de dónde viene el contexto, quién autorizó ese acceso, qué puede hacer la IA sin pedir permiso y cómo sabremos, en números, si valió la pena. Quien responde esas cuatro tiene un sistema; quien no las responde tiene una demostración.