Operar IA: las lecciones que no vienen en el manual

Durante muchos años aprendimos a implementar tecnología. Definíamos una necesidad, diseñábamos una solución, desarrollábamos o comprábamos un sistema, hacíamos pruebas, capacitábamos a los usuarios y finalmente llegaba ese momento que durante meses habíamos esperado: la salida a producción.

Si el proyecto había sido bien ejecutado, después venía cierta tranquilidad. El sistema comenzaba a formar parte de la operación, se estabilizaba y nuestra atención podía trasladarse al siguiente proyecto. Por supuesto que seguían existiendo actualizaciones, mantenimiento y soporte, pero conceptualmente la implementación había terminado.

Con la inteligencia artificial estoy aprendiendo que esa lógica ya no funciona igual. Hace tiempo escribí que la IA no se implementa, se opera. Lo que no sabía entonces era todo lo que realmente implicaba operarla. Porque una cosa es entender el concepto y otra muy distinta enfrentarlo en la práctica. Es ahí, cuando la IA deja el experimento y entra en la operación cotidiana del negocio, donde comienzan a aparecer las lecciones que no vienen en el manual.

Una solución basada en inteligencia artificial nunca está completamente terminada. Hay que observarla, medirla, corregirla, alimentarla, cuestionarla y mejorarla permanentemente. No basta con que hoy funcione correctamente, porque mañana cambiarán los datos, las condiciones del negocio, los usuarios, los modelos disponibles y probablemente también nuestras propias expectativas sobre lo que debería hacer.

La salida a producción, por lo tanto, deja de ser la meta. Es apenas el comienzo.

Hay que estar ahí

Una de las primeras lecciones que he aprendido es que no puedes operar inteligencia artificial desde lejos. Hay que estar ahí. Necesitas saber qué está haciendo, qué respondió, qué información recibió, qué decisión tomó, cuánto tardó, qué herramientas utilizó y, especialmente, qué ocurrió cuando algo salió mal.

Por eso los logs dejan de ser un elemento técnico para convertirse en una herramienta de gestión. Hay que registrar todo lo razonablemente posible: no solamente errores, también conversaciones, instrucciones, respuestas, tiempos, consumos, llamadas a servicios, versiones de prompts, decisiones, excepciones y cualquier elemento que posteriormente permita reconstruir lo ocurrido.

Porque cuando una IA hace algo inesperado, la pregunta más importante no es solamente qué pasó, sino por qué pasó. Y para responderla necesitamos hacer algo muy parecido a un análisis forense: reconstruir paso a paso el camino que siguió la solución hasta llegar a determinado resultado.

Sin trazabilidad solamente podemos especular; con trazabilidad podemos aprender. Y conforme las soluciones de inteligencia artificial comiencen a ejecutar procesos cada vez más importantes dentro de las organizaciones, esta capacidad dejará de ser deseable para convertirse en indispensable.

Los datos importan. Pero también importa dónde están.

Decir que los datos son importantes para la inteligencia artificial comienza a resultar casi obvio. Se ha repetido tantas veces que corre el riesgo de convertirse en una frase vacía. La pregunta que me parece mucho más relevante es otra: ¿dónde están esos datos?

Porque una cosa es tenerlos y otra completamente diferente poder verlos, consultarlos, relacionarlos y explotarlos. Una solución puede generar enormes cantidades de información y, paradójicamente, dejarnos prácticamente ciegos si esos datos permanecen encerrados dentro de una plataforma, un proveedor o una arquitectura que dificulta su acceso.

Por eso una de mis lecciones más importantes ha sido mantener los datos visibles. Las interacciones de los usuarios, los resultados, las excepciones, los consumos, los tiempos de respuesta, los errores y el comportamiento de los agentes deberían convertirse en información disponible para analizar la propia operación de la inteligencia artificial.

No se trata solamente de guardar datos. Se trata de construir observabilidad, porque aquello que podemos observar, podemos entender; y aquello que podemos entender, podemos mejorar.

Tercerizar capacidades no significa entregar el control

También he aprendido a diferenciar algo que puede parecer lo mismo, pero no lo es: contratar servicios externos y entregar la propiedad tecnológica. Puedes apoyarte en terceros para desarrollar aplicaciones, construir integraciones, diseñar agentes o acelerar determinados proyectos. En muchos casos incluso es conveniente hacerlo.

Pero la infraestructura crítica debe permanecer bajo tu control. Las cuentas, las licencias, los repositorios, las bases de datos, las llaves y los accesos deben pertenecer o estar administrados por la organización. Y, quizá todavía más importante, el conocimiento generado durante el desarrollo debe permanecer dentro de ella.

Puedes tercerizar el desarrollo. No deberías tercerizar el control. Esta diferencia se vuelve todavía más importante con inteligencia artificial porque las soluciones evolucionan rápidamente. El proveedor que hoy desarrolla una aplicación quizá mañana no sea quien la mantenga.

Si la arquitectura, las licencias, los datos y el conocimiento están bajo control de la empresa, cambiar de proveedor es una decisión operativa. Si no lo están, puede convertirse en una dependencia. Y la transformación digital no debería construir nuevas dependencias mientras intenta eliminar las anteriores.

En la era del no-code, entender código importa más

Existe otra paradoja que he ido confirmando conforme avanzo en este camino. Hoy podemos construir aplicaciones sin ser desarrolladores profesionales. Podemos describir lo que queremos, conversar con una inteligencia artificial y verla generar en minutos cantidades de código que antes habrían requerido días o semanas de trabajo.

Esto podría llevarnos a pensar que aprender código dejó de ser importante. Mi experiencia me está llevando exactamente a la conclusión contraria: en la era del no-code y de la inteligencia artificial, entender código importa más.

No necesariamente porque tengamos que escribir cada línea nosotros mismos. La IA puede hacerlo extraordinariamente bien. Pero necesitamos comprender lo suficiente para saber qué está haciendo, cómo está estructurada una aplicación, dónde guarda la información, cómo se conecta con otros sistemas, qué sucede cuando ejecuta determinada función y, especialmente, dónde buscar cuando algo falla.

Es una diferencia importante: ya no necesitas saber código solamente para programar; necesitas entenderlo para dirigir a quien programa, incluso cuando quien programa es una IA.

La inteligencia artificial está reduciendo drásticamente la barrera para construir tecnología, pero eso no elimina la necesidad de criterio técnico. Al contrario, la vuelve más relevante. Porque generar código se está volviendo barato y rápido; saber si ese código tiene sentido, si está bien construido, si es seguro y si responde verdaderamente a la necesidad del negocio continúa requiriendo conocimiento.

Quizá por eso aquella reflexión sobre la importancia del code en la era del no-code tiene hoy todavía más sentido. El no-code democratizó la capacidad de construir. La IA está llevando esa democratización mucho más lejos. Pero mientras más fácil sea crear, más importante será entender qué estamos creando.

No necesitamos convertir a todos en programadores. Pero quienes pretendemos liderar transformación digital difícilmente podremos conformarnos con observar la tecnología desde fuera. Hay que entender lo suficiente para poder entrar cuando sea necesario.

Un prompt nunca está terminado

Al principio resulta fácil pensar en el prompt como una instrucción. Lo escribimos, hacemos algunas pruebas, funciona y lo damos por terminado. Pero cuando comenzamos a operar soluciones reales descubrimos algo diferente: el prompt también es un activo vivo.

Debe evolucionar conforme conocemos nuevos casos, aparecen excepciones, cambian los procesos y aprendemos de los errores. Una palabra puede modificar un comportamiento. Una instrucción adicional puede resolver una excepción pero generar otra. Un ejemplo puede mejorar enormemente una respuesta y una regla demasiado rígida puede limitar algo que antes funcionaba correctamente.

Por eso los prompts deberían tener prácticamente la misma disciplina que aplicamos al software: versiones, pruebas, documentación, responsables y seguimiento de cambios. No se trata de encontrar el prompt perfecto, porque probablemente no existe; se trata de construir un proceso permanente para hacerlo cada vez mejor.

Cada error debería dejar conocimiento

Esto cambia incluso nuestra relación con los errores. En un sistema tradicional, un error generalmente provoca una corrección. En inteligencia artificial, un error debería provocar además aprendizaje.

¿Qué ocurrió? ¿Qué contexto recibió? ¿Qué información le faltó? ¿Qué interpretación hizo? ¿El problema estaba en los datos, en el prompt, en una integración, en una regla de negocio o simplemente encontramos un escenario que nunca habíamos considerado?

Si tenemos los logs adecuados, los datos visibles y la capacidad de reconstruir lo sucedido, cada excepción puede convertirse en conocimiento. Y ese conocimiento debería regresar al sistema, quizá como una modificación al prompt, una nueva regla, información adicional, una validación humana o incluso descubriendo que existen decisiones que simplemente no deberíamos delegar.

Por eso operar IA significa construir un ciclo permanente: observar → entender → aprender → corregir → volver a observar. No es solamente mantenimiento tecnológico; es una nueva disciplina operativa.

No confundir tendencia con estrategia

Existe finalmente otra lección que considero particularmente importante. La velocidad con la que evoluciona la inteligencia artificial genera una enorme ansiedad. Cada pocas semanas aparece un nuevo modelo, una nueva plataforma o una nueva capacidad que aparentemente cambia todo. De pronto alguien asegura que una herramienta es extraordinaria y sentimos que deberíamos estar utilizándola inmediatamente.

Es fácil caer en esa dinámica. Pero seguir tendencias no es tener una estrategia. Una organización no puede reconstruir permanentemente su arquitectura tecnológica alrededor de la herramienta que esa semana ocupa las conversaciones.

Hay que experimentar, por supuesto. Hay que probar, comparar y mantenerse curioso. Pero después hay que decidir. La estrategia consiste precisamente en establecer una dirección y desarrollar capacidades alrededor de ella, sin impedir que nuevas evidencias nos hagan cambiar cuando realmente exista una razón para hacerlo.

No deberíamos cambiar porque apareció algo nuevo. Deberíamos cambiar cuando lo nuevo demuestre ser mejor para nuestro propósito. La diferencia parece sutil, pero en términos de estrategia es enorme.

La verdadera implementación comienza después de implementar

Quizá la mayor lección que me está dejando esta etapa es que la inteligencia artificial exige una relación diferente con la tecnología. Ya no podemos pensar solamente en proyectos; tenemos que pensar en capacidades.

No basta con implementar una solución de IA y celebrar que salió a producción. Tenemos que construir alrededor de ella la capacidad organizacional para observarla, entenderla, corregirla y hacerla evolucionar. Eso significa tener personas responsables, datos visibles, trazabilidad, control tecnológico, conocimiento interno, entendimiento del código y una disciplina permanente de mejora.

Y posiblemente aquí se encuentre una de las diferencias más importantes entre las empresas que simplemente utilizarán inteligencia artificial y aquellas que verdaderamente aprenderán a competir con ella. Las primeras implementarán herramientas; las segundas desarrollarán la capacidad de operarlas.

Porque después de todo lo que he aprendido hasta ahora, cada vez estoy más convencido de algo: en inteligencia artificial, salir a producción no significa haber terminado. Significa que apenas comenzaste.