Conectar la IA al estado del sistema (sin filtrar secretos)
El estado de tu sistema vive en formatos distintos, repositorio, observabilidad, ticket, documentación, y cada uno pide un camino de conexión diferente. Errar el camino da una respuesta equivocada; olvidar la verificación de seguridad filtra secretos.
Le preguntas a la IA por qué el servicio de checkout está lento desde ayer. Ella responde con una explicación técnica llena de términos de arquitectura, e inventada. La IA nunca abrió tu panel de observabilidad ni tu repositorio, así que adivina una causa plausible.
El área legal pide la lista de licencias de librerías de código abierto usadas en el producto, cruzando el archivo de dependencias (dato estructurado) con el texto de la licencia de cada una (documento corrido). La IA devuelve una lista confiada, pero trató el archivo de dependencias como texto para buscar por significado, perdiendo la versión exacta de cada librería, y resumió el texto de la licencia de forma genérica sin notar la cláusula específica de esa versión. Una librería antigua, atascada en una versión con licencia distinta a la versión actual, fue clasificada mal porque la IA no leyó el archivo de dependencias como el dato estructurado que es. Formato equivocado, riesgo legal invisible: el archivo de dependencias pide lectura de estructura y versión exacta; el texto de licencia pide RAG completo, no resumen genérico.
Le pides a la IA que diga si el equipo de ingeniería está sobrecargado, cruzando el sistema de asistencia (dato estructurado) con las notas de one-on-one de los gerentes (texto corrido en documento). Devuelve una conclusión segura de "carga normal", pero trató el sistema de asistencia como texto para buscar por significado e ignoró la columna de hora extra, y trató las notas de one-on-one como planilla, perdiendo el tono de agotamiento que aparecía en las frases. El ingeniero que más señalaba agotamiento en las conversaciones desapareció del informe porque ninguna fuente se leyó de la forma correcta. Formato equivocado, diagnóstico equivocado: el dato estructurado pide razonamiento sobre schema; la nota de conversación pide búsqueda por significado.
Le pides a la IA que señale qué bug está trabando más la activación de usuario nuevo, cruzando el board de bugs (semiestructurado) con el funnel de analytics (dato estructurado). Devuelve un bug candidato, pero trató el board como texto suelto para buscar por significado, ignorando el campo de severidad, y trató el funnel de analytics como si necesitara búsqueda semántica en vez de cálculo directo sobre la tasa de conversión por etapa. El bug que realmente derrumbaba la activación estaba marcado con severidad alta en el board, un dato estructurado que la IA nunca miró como estructurado. Formato equivocado, priorización equivocada: el board de bugs pide campo estructurado combinado con texto; el funnel pide cálculo sobre dato estructurado.
Le pides a la IA que confirme, para el vendedor, si la API pública soporta un caso de uso específico que el prospecto preguntó, cruzando la documentación de la API (texto corrido) con el repositorio de código (estructura y dependencia). Devuelve una respuesta segura de "sí, lo soporta", pero solo leyó la documentación, que está desactualizada hace dos meses, sin verificar si el endpoint todavía existe en el repositorio real. El endpoint había sido eliminado en el último release, un hecho que solo el código, leído con razonamiento de estructura, revelaría. Formato equivocado, promesa equivocada al cliente: la documentación pide RAG, pero el código es la fuente de verdad sobre lo que existe ahora, y pide lectura de estructura.
Le pides a la IA que diga por qué el proceso automático de facturación falló para algunos clientes esta madrugada, cruzando el log de error (serie temporal estructurada) con el runbook de operación (texto corrido). Devuelve una causa probable, pero trató el log como texto para buscar por significado, perdiendo el patrón exacto de los horarios de falla, y trató el runbook como si fuera una lista de eventos. El patrón real, todas las fallas exactamente a las 3h, coincidiendo con una ventana de mantenimiento de la base de datos, solo aparece para quien mira el log como serie temporal estructurada. Formato equivocado, causa raíz perdida: el log estructurado pide lectura de serie temporal; el runbook pide RAG.
Le pides a la IA que confirme que ningún log de producción guarda CPF en texto plano, cruzando el código fuente de logging (estructura) con los logs ya almacenados en el sistema de observabilidad (dato histórico voluminoso). Devuelve "conforme", pero solo leyó el código actual con razonamiento de estructura, sin consultar el histórico de logs ya grabado hace dos años, que es una fuente de formato y volumen completamente distinto. El pasivo real, CPF ya guardado en logs antiguos antes de la corrección del código, quedó invisible porque la verificación miró la fuente equivocada para el tipo de riesgo en cuestión. Formato equivocado, auditoría incompleta: el código pide razonamiento de estructura; el histórico de log pide consulta directa al sistema de observabilidad, no inferencia sobre el código actual.
Le pides a la IA que encuentre dónde el usuario más abandona el flujo de registro, cruzando el evento de analytics (dato estructurado) con la grabación de sesión (contenido visual, no texto). Devuelve una pantalla candidata, pero trató el evento de analytics como texto para buscar por significado en vez de calcular la tasa de abandono por etapa, y no tuvo forma de "leer" la grabación de sesión, que exige un camino de lectura visual, no búsqueda textual. La etapa real de abandono, visible solo viendo la grabación, quedó fuera del diagnóstico porque la fuente correcta nunca se leyó de la forma que su formato exige. Formato equivocado, hallazgo incompleto: el evento de analytics pide cálculo sobre dato estructurado; la grabación de sesión pide lectura del contenido real, no inferencia sobre el evento.
Le preguntas a la IA si la plataforma aguanta el crecimiento de usuarios proyectado para el próximo año, cruzando la documentación de capacidad (texto corrido) con el panel de uso real (serie temporal estructurada). Devuelve una respuesta confiada de "aguanta con holgura", pero trató el panel de uso como texto para buscar por significado y perdió la tendencia real de crecimiento mes a mes, y trató el documento de capacidad como si fuera una tabla de números. El cuello de botella real, visible solo en la curva de crecimiento del panel, quedó invisible porque ninguna fuente se leyó de la forma correcta. Formato equivocado, decisión de inversión equivocada: el panel estructurado pide lectura de serie temporal; el documento de capacidad pide RAG.
Oye, fíjate en algo: el problema casi nunca es que la IA razone mal. El problema es que está respondiendo de memoria, sin haber abierto nunca el estado real de TU sistema. Es como contratar al mejor ingeniero sénior del mercado, sentarlo en tu mesa y nunca darle acceso a tu repositorio, a tu panel de observabilidad, a tu board de tickets. Va a hablar con seguridad y va a errar feo, porque está adivinando. Conectar la IA al estado del sistema es lo que la saca de lo genérico. Solo que conectar de la forma equivocada es peor: o lee el formato equivocado y erra el diagnóstico, o filtra secretos y credenciales que nunca deberían salir.
La idea central de esta lección. La IA solo ayuda de verdad cuando ve el estado real de tu sistema, y el FORMATO de cada fuente decide el camino. El repositorio de código pide razonamiento sobre estructura y dependencia, no búsqueda de fragmento parecido. La observabilidad y el log piden lectura de serie temporal estructurada, no búsqueda por significado en texto. El ticket semiestructurado combina campo estructurado con búsqueda por significado. La documentación de arquitectura, en texto corrido, es el territorio del RAG. Y antes de que cualquier cosa salga hacia un modelo externo, existe una verificación de seguridad que no es opcional: secreto, credencial y dato de cliente en log nunca salen sin enmascarar antes.
01El formato de la fuente decide el camino
El primer giro de llave es dejar de tratar "el estado del sistema" como una sola cosa. No existe un camino único para conectar la IA a lo que está pasando en tu entorno. Lo que existe es el formato de cada fuente, y el formato dicta el camino.
Piensa en cuatro naturalezas distintas que conviven en cualquier equipo de tecnología. Está el repositorio de código, que no es texto suelto: es estructura, carpeta, módulo, grafo de dependencia entre función y servicio. Está la observabilidad, métrica y log, que es serie temporal estructurada: número en el tiempo, con timestamp, con conteo. Está el ticket, que es semiestructurado: campo fijo (severidad, estado, responsable) mezclado con descripción en texto libre. Y está la documentación de arquitectura, el runbook, el texto corrido de verdad, donde la idea vive en frase y párrafo.
Cada una pide una herramienta distinta, y el error más común es tratar de meter las cuatro en el mismo camino, generalmente el RAG tradicional, creyendo que texto es texto. El estudio de @datasciencebrain apunta exactamente a esto: el formato del dato decide la arquitectura de memoria, no al revés.
02Repositorio y observabilidad: razonamiento sobre estructura, no búsqueda vectorial ingenua
Aquí vive el error más común de quien acaba de aprender RAG y trata de aplicarlo a todo: creer que meter el repositorio entero en un índice vectorial resuelve el problema. No lo resuelve, y en el repositorio el costo del error es específico: el código no es una colección de párrafos parecidos, es un grafo. La función A llama a la función B, que es importada por el servicio C, del que otro equipo depende sin saberlo. Si preguntas "qué se rompe si cambio esta función" y la IA solo busca "fragmentos de texto parecidos a esta función", encuentra los lugares obvios y pierde las siete llamadas escondidas en otro repositorio, otro servicio, otro contexto de import.
El camino correcto es darle a la IA la estructura: el árbol de carpetas, el grafo de dependencia entre módulos y servicios, el historial de commits relevante, y dejar que razone sobre eso, no que solo busque por similitud textual. Es la diferencia entre preguntar "qué párrafos se parecen a este" y preguntar "quién depende de esto de verdad".
La observabilidad tiene el mismo problema con otra cara. Métrica y log son serie temporal: número, con timestamp, con conteo por minuto. Preguntar "este log de error tiene relación con el deploy" no es una pregunta de significado textual, es una pregunta de correlación en el tiempo: cuándo empezó exactamente el error, cuándo ocurrió exactamente el deploy, y la distancia entre ambos es el dato que importa. Buscar "textos parecidos" entre logs de antes y después del deploy es el camino equivocado; mirar el conteo de error por minuto, cruzado con el timestamp exacto, es el camino correcto.
03Documentación y ticket: RAG y búsqueda por significado
Ahora los dos formatos donde la búsqueda por significado, el RAG de verdad, tiene sentido. La documentación de arquitectura, el runbook, el texto de decisión técnica: eso es texto corrido, exactamente el territorio donde buscar por significado funciona bien. Preguntas "cómo decidió el equipo manejar el timeout de pago" y la búsqueda semántica encuentra el fragmento correcto, aunque el documento use otra palabra para describir lo mismo.
Sabe más: por qué el ticket no es ni puramente estructurado ni puramente texto
Un ticket parece una línea de planilla a primera vista, tiene severidad, estado, responsable, fecha. Pero la parte que más importa para la priorización real suele estar en la descripción en texto libre, donde la persona que abrió el ticket explica lo que está pasando con sus propias palabras. Tratar el ticket solo como dato estructurado ignora ese relato; tratarlo solo como texto para búsqueda semántica ignora el campo de severidad que ya viene listo y es más confiable que cualquier inferencia sobre el texto. El camino correcto es siempre ambos juntos: usa el campo estructurado para filtrar y ordenar (severidad alta, abierto hace mucho tiempo, reabierto más de una vez), y usa búsqueda por significado dentro de la descripción para agrupar duplicados y entender el relato real detrás del número. Ignorar cualquiera de los dos lados es el error que hace que el ticket correcto desaparezca en el medio del board.
El ticket, entonces, pide los dos: el campo estructurado (severidad, estado, tiempo abierto) para filtrar y ordenar, y búsqueda por significado en la descripción para agrupar y entender el relato. Tratar el ticket solo como texto pierde la señal confiable del campo; tratarlo solo como planilla pierde el relato que solo existe en lenguaje natural.
04Seguridad: secreto y dato de cliente en el log nunca salen sin verificación
Todo lo visto hasta aquí fue sobre hacer que la IA acierte el diagnóstico. Ahora el punto que, en el área de tecnología, puede costar mucho más caro que un diagnóstico equivocado: lo que sale de la empresa cuando conectas la IA a tu repositorio y a tu log de producción.
En el instante en que le das acceso a esas fuentes, existe una pregunta que necesita venir antes que cualquier otra: qué hay ahí que es secreto, credencial o dato de cliente, y eso puede ir a un modelo externo sin enmascarar? El repositorio de código suele tener clave de API, token, string de conexión de base de datos, todo eso a veces hardcodeado en un archivo viejo que nadie recuerda que existe. El log de error en producción suele cargar dato de cliente sin querer: CPF, correo, número de tarjeta, todo eso puede aparecer en un stack trace que nadie pensó en enmascarar antes de loguearlo.
Ya viste, en la lección de conectar la IA a los números del módulo financiero, el mismo gateway que bloquea lo que no puede pasar y registra lo que pasó. Aquí el principio es idéntico, solo que aplicado a tu fuente específica: antes de que el agente lea el repositorio entero o consulte el log de producción, el secreto necesita estar fuera del camino, ya sea porque el repositorio ya sigue buenas prácticas de no versionar credenciales, ya sea porque el log pasa por una capa de enmascaramiento antes de llegar a un modelo externo. No es burocracia. Es la diferencia entre "conecté la IA a mi sistema" y "filtré una credencial de producción sin darme cuenta".
05Uniendo todo: del sistema opaco al sistema que la IA de verdad ve
Ahora se puede ver el cuadro completo. Conectar la IA al estado del sistema es lo que la saca de responder de memoria, es lo que hace que deje de adivinar la causa raíz y empiece a razonar sobre tu repositorio, tu panel, tu ticket real. Pero conectar es un arma de doble filo: conectar en el formato equivocado da una respuesta equivocada con cara de correcta, y conectar sin verificación de seguridad filtra lo que nunca debería salir.
La secuencia que protege al equipo es siempre la misma. Primero, mira el FORMATO de la fuente y elige el camino: el repositorio se convierte en razonamiento sobre estructura y dependencia, la observabilidad se convierte en lectura de serie temporal, el ticket se convierte en campo estructurado combinado con búsqueda por significado, la documentación se convierte en RAG. Segundo, antes de conectar cualquier cosa a un modelo externo, pasa por la verificación de seguridad: hay secreto, credencial o dato de cliente ahí, necesita enmascararse, corre local o en la nube, el gateway está en el medio. Formato primero, seguridad siempre.
Hazlo ahora
Toma una pregunta real sobre tu sistema que la IA respondió de memoria y erró, o que todavía ni siquiera intentaste responder con IA: tu tarea real.
- Enumera 3 fuentes que contendrían la respuesta correcta (repositorio, panel de observabilidad, board de tickets, documentación de arquitectura, log de producción).
- Para cada fuente, clasifica el FORMATO: estructura y dependencia (código), serie temporal (métrica y log), semiestructurado (ticket), o texto corrido (documentación).
- Marca el camino de cada una: el código lleva a razonamiento sobre estructura, la observabilidad lleva a lectura de serie temporal, el ticket lleva a campo estructurado más búsqueda por significado, la documentación lleva a RAG.
- Haz la verificación de seguridad de cada fuente en una línea: hay secreto, credencial o dato de cliente ahí? Necesita enmascararse? Corre en la nube o pide entorno cerrado?
- Señala cuál fuente es la más sensible de las tres y escribe, en una frase, qué debería bloquear el gateway en ella.
Acabas de diseñar la conexión de tu sistema con la IA por el camino correcto, con el portón de seguridad en su lugar. Estás por delante de quien solo pega el log entero en un chat y cruza los dedos.
Practica
1. Quieres saber qué se rompe si cambias una función del repositorio. ¿Cuál es el camino más indicado?
2. ¿Por qué preguntar 'el log de error de ayer tiene relación con el deploy de las 21h' no debe tratarse como búsqueda por significado en texto?
3. Antes de conectar la IA a tu repositorio y a los logs de producción, ¿cuál es la postura correcta?
Para la pizarra
Sobre el diagnósticohabla con seguridad y se equivoca feo porque nunca abrió tu repositorio, tu panel, tu board.
Sobre el formatocada fuente tiene naturaleza propia. Log, ticket y código no se conectan de la misma forma.
Sobre el secretoconectar no es abrir todo. Una credencial nunca entra en el contexto, por ninguna comodidad.
Gracias por el feedback. Esto ayuda a afinar la próxima lección.