Cuanto más entra la palabra «IA» en nuestro vocabulario, menos explica. Desmitificar empieza por separar las capas antes de discutir la magia.

TL;DR

La inteligencia artificial no es una pieza única. Un modelo transforma entradas en salidas; una automatización recorre etapas predefinidas; un agente puede elegir los siguientes pasos y usar herramientas dentro de ciertos límites; un harness organiza a su alrededor contexto, memoria, skills, fuentes, permisos, puntos de aprobación y validaciones. Las fronteras no son universales, pero distinguirlas evita esperar comprensión humana de una interfaz, autonomía de un modelo aislado o seguridad de un prompt bien escrito. La dirección sigue siendo humana. El sistema sirve para transformar esa dirección en una ejecución más legible, gobernada y verificable.

«La IA lo hizo».

La frase puede ser correcta. Casi siempre está incompleta.

Después de años construyendo software y, más recientemente, orquestando agentes, automatizaciones, memoria, skills, subagentes, herramientas, permisos y validaciones, la trato como una solicitud de aclaración.

¿Qué parte del sistema hizo exactamente qué?

¿Fue un modelo generando texto? ¿Una búsqueda recuperando documentos? ¿Un flujo siguiendo reglas? ¿Un agente eligiendo herramientas? ¿Un programa tradicional calculando el resultado? ¿Una persona aprobando la acción? ¿Todo junto?

Llamar «IA» a cada una de esas cosas es como llamar «coche» al motor, la caja de cambios, el conductor, la carretera y las normas de tránsito, y esperar que el mecánico descubra el resto por el contexto.

A veces lo descubre.

A veces el presupuesto también te descubre a ti.

Desmitificar la inteligencia artificial no significa fingir que todo se volvió sencillo. Significa separar las capas lo suficiente para hacer mejores preguntas. Empecé a tomarme esta distinción más en serio cuando percibí que una palabra demasiado amplia escondía decisiones completamente diferentes: elegir un modelo, automatizar un proceso, delegar acciones o gobernar una operación no son variaciones del mismo problema.

Primero: ¿de qué IA estamos hablando?

«Inteligencia artificial» es un paraguas enorme. Cubre técnicas, sistemas y aplicaciones muy diferentes: reconocimiento de imágenes, predicción, recomendación, planificación, procesamiento del lenguaje, robótica y mucho más.

En este texto me concentro en sistemas generativos basados en grandes modelos de lenguaje y en las arquitecturas de agentes construidas a su alrededor. No estoy diciendo que toda IA funcione como un chatbot ni que todo sistema inteligente use las mismas técnicas.

La propia OCDE, al explicar la definición actualizada de sistema de IA, reconoce que no existe una línea roja simple que separe la IA de lo que no es IA. Su definición describe un sistema basado en máquinas que, a partir de entradas y objetivos explícitos o implícitos, infiere cómo generar predicciones, contenido, recomendaciones o decisiones capaces de influir en entornos físicos o virtuales.

Esa formulación es útil por un motivo que suele desaparecer en la publicidad: habla de un sistema, no de una entidad mágica.

Y, dentro del sistema, el modelo es solo un componente.

El mapa en una página

Las palabras varían entre empresas, artículos y herramientas. La tabla siguiente no pretende cerrar la terminología; ofrece un mapa operativo para este blog.

Capa	Qué hace	Qué no garantiza
Modelo	Transforma una entrada en una salida a partir de patrones aprendidos	Una fuente correcta, un objetivo adecuado, memoria duradera o acceso a sistemas externos
Automatización	Ejecuta una secuencia de etapas, reglas e integraciones	Criterio ante situaciones no previstas o una decisión responsable
Agente	Usa un modelo para elegir pasos, consultar contexto y activar herramientas dentro de un objetivo	Autonomía ilimitada, fiabilidad o permiso para actuar sobre cualquier cosa
Harness	Organiza entorno, contexto, memoria, skills, herramientas, fuentes, permisos, checkpoints y validaciones	Verdad automática, riesgo cero o buena dirección humana

La cuestión no es memorizar los nombres.

Es entender que cada capa resuelve un problema diferente y crea un tipo distinto de riesgo.

Modelo: el motor no es toda la operación

Un modelo recibe entradas y produce salidas.

En el caso de un gran modelo de lenguaje, esto implica aprender regularidades a partir de grandes conjuntos de datos y generar secuencias compatibles con el contexto recibido. La salida puede ser excelente, mediocre, errónea o inventada con una fluidez que hace más difícil detectar el error.

El perfil de IA generativa del NIST usa el término confabulación para referirse a salidas falsas o erróneas presentadas con seguridad. El documento explica que los modelos generativos aproximan distribuciones estadísticas de los datos de entrenamiento y que los grandes modelos de lenguaje predicen el siguiente token. Esto puede producir contenido correcto y coherente; también puede producir algo factualmente erróneo o internamente contradictorio.

La plausibilidad lingüística no es una prueba.

El modelo no es automáticamente una base de datos, un motor de búsqueda, una política de acceso, un proceso de negocio ni una fuente de verdad.

Tampoco posee voluntad propia. Cuando parece perseguir un objetivo, hay una combinación de entrenamiento, instrucciones, contexto, código y decisiones humanas produciendo ese comportamiento.

Por eso un prompt puede mejorar una respuesta sin convertir el modelo en un sistema gobernado.

El prompt informa una tarea. Por sí solo, no crea control de acceso, historial fiable, aprobación humana, observabilidad, pruebas, rollback ni responsabilidad.

Un motor potente todavía necesita todo lo demás. La industria tardó décadas en construir esas capas, como conté al recorrer la evolución desde el mainframe hasta los agentes.

Automatización: cuando el camino ya puede dibujarse

La automatización es la ejecución de un proceso mediante reglas e integraciones.

Puede usar IA, pero no tiene por qué hacerlo.

Un flujo hipotético puede recibir un documento, validar campos obligatorios, consultar un registro, guardar el resultado y enviar una notificación. Si se conocen las etapas y las excepciones relevantes, el código tradicional o una herramienta de automatización de flujos puede resolver el problema con más previsibilidad, menor coste y menos espacio para improvisar.

Eso no es menos moderno.

Es ingeniería eligiendo una herramienta proporcional al problema.

Muchas cosas que se venden como «agente» son, en la práctica, una automatización con una llamada a un modelo en medio. No hay nada malo en ello. El error empieza cuando el nombre más vistoso crea expectativas que la arquitectura no cumple.

Agente: autonomía delegada, no personalidad

No existe una definición universal de agente.

Una referencia de ingeniería de Anthropic distingue los flujos de trabajo, en los que modelos y herramientas recorren caminos predefinidos, de los agentes, en los que el modelo dirige dinámicamente el proceso y el uso de herramientas. Es una taxonomía de la propia empresa, no una ley de la informática, pero ayuda a localizar el cambio principal.

En un agente, el modelo no produce solo una respuesta final. Puede observar el estado, elegir el siguiente paso, activar una herramienta, evaluar el resultado y continuar hasta concluir, fallar o alcanzar un límite.

Eso no lo convierte en trabajador humano, compañero afectivo ni dueño de la decisión.

La autonomía del agente fue delegada por alguien. Su objetivo fue definido o aceptado por alguien. Sus herramientas fueron expuestas por alguien. Sus permisos deben ser limitados por alguien. Y sus acciones materiales siguen exigiendo responsabilidad humana y organizacional.

Cuanto mayor sea la autonomía, más importante resulta responder:

• ¿qué puede ver el agente?
• ¿qué puede modificar?
• ¿cuándo debe pedir aprobación?
• ¿cómo se registrará su acción?
• ¿qué validación separa un intento de una entrega?
• ¿cómo se interrumpe o revierte algo que sale de lo previsto?

Los subagentes no cambian esa naturaleza. Son una forma de dividir contexto, especialidad y revisión entre instancias o funciones. No forman un equipo humano dentro de la máquina.

Harness: el sistema que vuelve operativo al agente

En esta capa concentro buena parte de mi trabajo actual.

Un modelo mejor ayuda. Pero cambiar de modelo no resuelve por sí solo el contexto disperso, las instrucciones contradictorias, la memoria sin origen, una herramienta sin permiso, una decisión sin responsable o una entrega sin validación.

Uso harness para nombrar el sistema que rodea al agente. Su función puede resumirse en tres compromisos:

• hacer que el contexto sea legible, para que las reglas, las fuentes, el historial y el objetivo no dependan de una conversación perdida;
• hacer que la acción sea gobernable, con herramientas, permisos, puntos de aprobación, criterios de parada y responsables definidos;
• hacer que el resultado sea verificable, con pruebas, registros y evidencia suficiente para revisar, corregir o rechazar la entrega.

La memoria, las skills, los subagentes y las herramientas son formas de implementar esos compromisos. No son personajes: la memoria es información recuperable; una skill es un procedimiento reutilizable; un subagente es otra ejecución con contexto y función delimitados.

Un relato de OpenAI sobre harness engineering con Codex describe la importancia de hacer legibles para los agentes el contexto, las herramientas, la documentación y los ciclos de feedback. Es un caso específico de la empresa, no una receta universal. La distinción útil es esta: la capacidad del modelo y la calidad del entorno son problemas diferentes.

La base operativa que construí ya puede transformar criterios humanos en una ejecución reutilizable, gobernada y verificable. No es un modelo fundacional propietario; es una arquitectura que combina componentes y contratos de trabajo.

La mejor respuesta no es la más agradable

Existe otra capa que un diagrama técnico suele esconder: el comportamiento que elegimos incentivar.

No perfecciono mis agentes para recibir una conformidad más elegante. Quiero la mejor respuesta verificable que permitan el contexto y las fuentes, incluso cuando señala que mi pregunta está mal formulada, que falta evidencia o que estoy defendiendo una hipótesis demasiado pronto.

Un estudio sobre sycophancy en modelos de lenguaje encontró situaciones en las que se favorecían respuestas alineadas con las creencias del usuario incluso cuando eso competía con la corrección. El trabajo no representa todos los modelos ni contextos, pero respalda una precaución importante: la agradabilidad no es una métrica suficiente de calidad.

Por eso mis contratos piden que el agente exponga la incertidumbre, busque contrapuntos, señale puntos ciegos y haga preguntas cuando la ambigüedad pueda cambiar la ejecución.

Si todavía no está claro qué debe hacerse, no quiero que un verbo en imperativo convierta la confusión en acción.

La dirección es mía.

El papel del sistema es ayudar a hacerla más explícita, confrontarla con la realidad y ejecutarla dentro de ciertos límites.

Este criterio se desarrolla en «La mejor respuesta no es la que más me agrada».

Por qué confundir las capas sale caro

Cuando todo recibe el mismo nombre, preguntas diferentes parecen tener la misma respuesta.

Una empresa puede contratar un modelo esperando que conozca sus procesos. Puede comprar una plataforma de agentes cuando una automatización sencilla bastaría. Puede liberar una herramienta crítica porque el chatbot respondió bien durante una demostración. Puede llamar memoria corporativa a una carpeta de conversaciones. Puede tratar un prompt como una política de seguridad.

El resultado no siempre es una catástrofe cinematográfica.

A veces es peor: una colección silenciosa de decisiones difíciles de auditar, integraciones frágiles, trabajo manual escondido y confianza que crece más rápido que la evidencia.

Separar las capas permite elegir el control correcto:

• el modelo exige evaluación de calidad, límites y comportamiento;
• la automatización exige reglas, tratamiento de excepciones y observabilidad;
• el agente exige alcance, herramientas, permisos y criterios de parada;
• el harness exige gobernanza, responsabilidad definida, memoria, validación y mantenimiento continuo.

No existe una arquitectura que lleve el riesgo a cero. Existe una arquitectura que vuelve el riesgo más visible, limitado y tratable.

La gobernanza no es un documento que se añade al final

Cuando un sistema puede influir en decisiones o actuar sobre una operación, la gobernanza debe nacer junto con la arquitectura.

El AI Risk Management Framework 1.0 del NIST organiza la gestión del riesgo en funciones como gobernar, mapear, medir y gestionar. El framework es voluntario y amplio. No certifica una herramienta específica, no garantiza conformidad y no sustituye los controles técnicos, jurídicos u organizacionales de cada contexto.

Su valor para esta conversación está en desplazar la pregunta.

En lugar de «¿qué IA vamos a usar?», empezamos a preguntar:

• ¿qué decisión o proceso está en juego?
• ¿quién puede verse afectado?
• ¿qué datos y fuentes sostienen la salida?
• ¿qué nivel de error es tolerable?
• ¿dónde es obligatoria la supervisión humana?
• ¿cómo medimos el comportamiento y la calidad después del lanzamiento?
• ¿quién puede interrumpir, corregir y responder por el sistema?

La gobernanza no es el freno que se instala después de acelerar.

Es parte de la dirección.

Cuándo no usar un agente

Desmitificar la IA también significa admitir cuándo no es la mejor solución.

Yo empezaría por algo más sencillo cuando:

• las reglas son estables y pueden codificarse directamente;
• el error aceptable es cercano a cero y no existe una validación segura;
• los datos necesarios no pueden exponerse al modelo o a la plataforma;
• no hay un responsable que apruebe acciones, supervise resultados y responda por fallos;
• el coste de la imprevisibilidad supera el beneficio de la flexibilidad;
• una persona puede resolver el caso excepcional mejor que un sistema permanente.

Los agentes son útiles cuando existe variabilidad real, contexto suficiente, herramientas bien delimitadas y criterios de evaluación. Fuera de eso, añadir autonomía puede ser solo una forma cara de volver el error más creativo.

Qué tiene que ver esto con i-9.ai

Esta separación de capas ya orienta lo que puedo entregar a través de i-9.ai.

No empezar por la herramienta de la semana. Empezar por la operación.

Entender el problema, los datos, las decisiones, las personas y los riesgos. Descubrir si la respuesta requiere software, automatización, un modelo, un agente, un harness completo o ninguna de esas cosas. Solo entonces diseñar una solución personalizada y gobernada.

La base es reutilizable y algunas automatizaciones están lo bastante maduras como para replicarlas casi por completo. Eso no elimina la adaptación: las integraciones, los permisos, los datos, los riesgos y los procesos siguen perteneciendo al contexto de cada cliente.

Siempre que el problema lo permite, prefiero código abierto, infraestructura privada y soberanía sobre los datos, las políticas y la operación. No es un dogma ni una promesa de aislamiento absoluto. Las dependencias externas útiles deben evaluarse, declararse y gobernarse.

El principio de la entrega se mantiene: la tecnología debe ampliar la capacidad sin esconder dependencia, incertidumbre ni responsabilidad. Si esta forma de pensar se parece a lo que necesita tu empresa, ponte en contacto. La conversación empieza por la operación, no por la herramienta de la semana.

Siete preguntas antes de aceptar «vamos a poner IA»

Cuando la próxima conversación empiece con esa frase, intenta devolver siete preguntas:

1. ¿Qué resultado concreto debe cambiar?
2. ¿Estamos pidiendo una respuesta o autorizando una acción?
3. ¿Qué datos, fuentes y contexto podrá usar el sistema?
4. ¿El camino puede automatizarse o exige decisiones dinámicas?
5. ¿Qué herramientas y permisos serán realmente necesarios?
6. ¿Quién verifica, aprueba y responde por las decisiones materiales?
7. ¿Cómo detectamos un fallo, interrumpimos la ejecución y volvemos a un estado seguro?

Si nadie puede responderlas, el proyecto todavía no está listo para acelerar.

Quizá solo esté listo para pensar mejor.

Y eso ya es un comienzo.

Desmitificar la IA no empequeñece la tecnología. Hace lo contrario: le quita la obligación de sostener una fantasía y permite ver dónde existe realmente la capacidad.

Cuando la magia sale de escena, entran la arquitectura, el contexto, el criterio, los límites y la responsabilidad.

Ahí es donde la inteligencia artificial empieza a ser útil.

Sigue leyendo

• La mejor respuesta no es la que más me agrada: cómo transformar el criterio contra la adulación en contexto, permisos, checkpoints y validaciones.
• Evolución de la tecnología: del mainframe al juego de palabras infame en tiempo real: la línea histórica que hizo posible conversar con sistemas capaces de usar contexto y herramientas.
• La previsibilidad seductora de la IA: por qué una interfaz fluida y personalizada sigue siendo diferente de la reciprocidad humana.

Referencias y límites de uso

Las fuentes siguientes respaldan definiciones, distinciones o prácticas específicas. Ninguna demuestra que una arquitectura concreta será segura, eficaz o adecuada sin evaluar su contexto.

• OCDE.AI, “What is AI? Can You Make a Clear Distinction Between AI and Non-AI Systems?” (2024) (consultado el 26 de agosto de 2026): explica la definición actualizada de sistema de IA y distingue modelo de sistema; reconoce que no existe una frontera simple y universal.
• Anthropic, “Building Effective Agents” (2024) (consultado el 26 de agosto de 2026): presenta la distinción que usa la empresa entre workflows predefinidos y agentes que dirigen dinámicamente el uso de herramientas; no es una normalización universal.
• Sharma et al., “Towards Understanding Sycophancy in Language Models” (2023): investiga la sycophancy en cinco asistentes y el papel de los datos de preferencias; no representa todas las versiones, arquitecturas o situaciones de uso.
• NIST, “Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile” (2024): define y contextualiza los riesgos de confabulación en IA generativa; no implica que toda salida sea falsa ni evalúa un modelo específico de este artículo.
• NIST, “Artificial Intelligence Risk Management Framework 1.0” (2023): framework voluntario para gobernar, mapear, medir y gestionar riesgos de IA; no es una certificación ni una garantía de conformidad o seguridad.
• OpenAI, “Harness Engineering: Leveraging Codex in an Agent-First World” (2026) (consultado el 26 de agosto de 2026): relato de ingeniería sobre contexto legible, documentación, herramientas y ciclos de feedback en un proyecto específico con Codex; no demuestra su adecuación para todas las organizaciones.