Copiloto o Motor: las Dos Formas de Meterle IA a un Sistema

Me tocó dar una plática en la inauguración de ALTI (Alianza de Líderes en Tecnología e Innovación), y abrí con una pregunta de mano alzada: ¿quién ya «le metió IA» a algo este año? Se levantaron casi todas las manos. Entonces vino la segunda pregunta, la incómoda: ¿le metiste un copiloto que platica y decide, o un motor que transforma datos sin abrir la boca?

Ahí la sala se quedó callada. Y es normal, porque «le metimos IA» se dice igual para dos cosas que no se parecen en nada. Confundirlas es la razón número uno por la que un proyecto de IA se siente mágico en la demo y se cae en producción. Este post es esa plática, por escrito.

Hoy la IA entra a un sistema por dos puertas

Después de meterle IA a sistemas reales —de clientes y míos— me quedé con un mapa muy simple. Solo hay dos formas de integrarla:

• Tipo 1 — Conversacional / Agéntica. La IA conversa, razona, decide y usa herramientas. Es un copiloto.
• Tipo 2 — Pasiva / Como función. La IA es un paso dentro de un flujo. Entra dato, sale dato. Es un motor.

La analogía que usé en el escenario fue la del auto:

El copiloto es agéntico. Le dices a dónde quieres llegar y él elige la ruta, ve el tráfico, recalcula y te avisa. Tú supervisas, él opera.

El motor es la IA como función. No decide a dónde vas. Hace una sola cosa, muy bien, cada vez que pisas el acelerador. Predecible, medible, callado.

No se trata de cuál es mejor. Se trata de cuál pide tu problema.

Tipo 1 — IA Agéntica: el copiloto

Un sistema agéntico corre un loop: recibe un objetivo en lenguaje natural, razona un plan, llama herramientas (tool calling), observa el resultado, se autocorrige si algo falló, y responde cuando logró la meta. La clave de todo está en una frase: el modelo controla el flujo. Es él quien decide el siguiente paso, no tu código.

Por eso un sistema agéntico se siente distinto: conversa y mantiene contexto, decide qué herramienta usar y cuándo, actúa (APIs, MCP, navegar, escribir archivos), ve su propio error y reintenta solo. Y dos rasgos que hay que tener muy presentes: es no-determinista (dos corridas, dos caminos) y requiere supervisión —humano supervisa, agente opera—.

Caso real: un agente que opera la infraestructura

El ejemplo que enseñé es mi propio stack: OpenClaw + Claude Code + ProjectHub (con memoria por embeddings). Le pido una tarea de infra en lenguaje natural; busca en su memoria, elige herramientas y ejecuta; si un comando falla, lee el error y vuelve a intentar. Y ya hay agentes que se coordinan entre sí. Su naturaleza es abierta: el camino lo decide el modelo en cada corrida.

Cuándo conviene el copiloto

Usa agéntico cuando el problema es abierto y cada caso es distinto, cuando hay que decidir entre muchas herramientas, cuando el valor está en el criterio y la conversación, y cuando hay un humano que puede supervisar.

No lo uses cuando necesitas el mismo resultado siempre, cuando el volumen es alto y el margen de error nulo, cuando no puedes pagar latencia ni variabilidad, o cuando debe correr solo sin nadie mirando.

Tipo 2 — IA como función: el motor

Aquí la IA es una función pura dentro de un workflow. Entra un dato estructurado, hay un paso previo de reglas o parseo, un LLM acotado hace una sola tarea, el código valida la salida, reintenta hasta N veces si no cumple, y sale un dato estructurado. La clave, otra vez en una frase: el flujo lo controla TU código. La IA es solo un nodo.

Y se siente al revés que el agente: no conversa (sin chat, sin contexto largo), entra y sale con un contrato fijo de datos, hace una tarea acotada y repetible, es verificable (el código valida), medible (runs, latencia, error rate) y corre desatendida, a escala.

Caso real: validación documental en una agencia aduanal

El segundo ejemplo es un sistema en producción para una agencia aduanal: validación de pedimentos con IA embebida en un workflow (Dify + Ollama). Cada bloque del pedimento entra como dato estructurado; el LLM valida y corrige NOMs, permisos y exenciones —una sola tarea—; el código verifica el bloque y, si no cumple, reintenta (hasta 3). Sale el bloque corregido. Nadie chatea con la IA: es un paso del flujo. Lleva más de 3,600 corridas acumuladas, una llamada por bloque, desatendido.

Cuándo conviene el motor

Usa la IA como función cuando la tarea es repetible y bien definida, cuando necesitas resultados consistentes y medibles, cuando el volumen es alto y debe correr solo, y cuando puedes validar la salida con código.

No la uses cuando el problema es abierto o cambia cada vez, cuando hace falta criterio y conversación, cuando no hay forma de validar la salida, o cuando hay que decidir entre muchas herramientas.

La misma IA, dos formas de integrarla

Si lo ponemos lado a lado, la diferencia es nítida:

• Quién controla el flujo: el modelo (agéntica) vs tu código (función).
• Interfaz: conversación vs entrada → salida.
• Herramientas: decide cuáles y cuándo vs ninguna o fijas.
• Resultado: no-determinista vs consistente.
• Supervisión: humano en el loop vs desatendido.
• Métrica clave: calidad del criterio vs error rate y latencia.
• Ejemplo: agente de infra vs workflow aduanal.

El truco: no es elegir uno, es saber cuál va dónde

Y aquí cerré la plática, porque es la parte que de verdad importa. Esto no es una guerra de o/o. El agente agéntico, por dentro, llama funciones. El workflow de funciones puede tener un agente arriba que lo dispara. La madurez en IA no es usar el modelo más grande ni el framework de moda: es poner cada tipo donde rinde. Lo abierto, al copiloto. Lo repetible, al motor.

Así que la próxima vez que alguien diga «le metimos IA», la pregunta correcta no es qué modelo usaron. Es: ¿copiloto o motor? Y esa respuesta empieza por el problema, no por el modelo.

Gracias a ALTI por el espacio en su inauguración. Si te late seguir la conversación, por aquí sigo escribiendo lo que voy aprendiendo metiéndole IA a sistemas reales.