El límite no es la IA: es cuánto te cuesta verificarla

Este artículo responde a la columna El límite infinito: la evolución hacia la inteligencia artificial autocalibrable, de Francisco "Pacho" Camacho, publicada en Startups Latam en octubre de 2026. Pacho es físico, emprendedor y amigo mío desde hace años. Lo que sigue es una conversación que empezamos en persona y que vale la pena seguir por escrito.

Pacho cuenta una escena que yo también he visto decenas de veces. En un taller con un equipo técnico o con fundadores, alguien le pide algo a un modelo de lenguaje, recibe una respuesta inesperada y se bloquea. Espera que el software se comporte como software: entrada, salida, error. Lo que Pacho propone es simple y, en mi experiencia, cierto: pregúntale al modelo qué quiso decir y cómo lo resolvería. "Por primera vez en la historia de la computación, contamos con una tecnología auto explicable". De ahí construye una tesis más ambiciosa: con bucles de retroalimentación bien diseñados, la IA puede ejecutar tareas de forma autónoma con un techo "prácticamente infinito", y la barrera para llegar ahí es mental, no técnica. "El límite lo marca la curiosidad del usuario".

Estoy de acuerdo con casi todo. Y justamente porque estoy de acuerdo, quiero empujar la tesis un paso más allá de donde la deja la columna. Pacho escribe pensando en código y en startups. Yo paso la semana con gerentes de empresas medianas que no escriben código y que quieren saber dónde poner IA sin que les explote. Para ellos, la pregunta no es si el límite es infinito. Es cuánto cuesta verificar lo que la IA hizo. Ese costo es el límite real, y conocerlo te dice por dónde empezar.

En qué tiene razón Pacho

Trabajar con un modelo se parece más a trabajar con un colega que a consultar una base de datos. Los errores se corrigen preguntando, no reiniciando. Esto parece obvio hasta que ves a un director financiero cerrar la ventana porque el modelo le respondió "algo raro". Lo que sigue a esa respuesta rara casi siempre es una pregunta de dos líneas, y el resultado mejora.

Auditar línea por línea no escala. La frase de Pacho es exacta: "Auditar manualmente miles de líneas de código es insostenible y genera un cuello de botella". Lo he vivido en equipos de pagos donde la revisión de código se volvió el paso más lento del ciclo, mucho antes de que existieran los agentes. Con agentes que generan diez veces más código, pretender revisar todo a mano es una fantasía. La respuesta correcta es la que él describe: especificaciones rigurosas, pruebas automatizadas y un entorno donde el sistema se corrige solo hasta que las pruebas pasan.

La alucinación tiene un lado útil. Pacho la llama la fuente de soluciones originales, y es verdad cuando la tarea es abierta: proponer enfoques, generar alternativas, escribir código que luego pasa por pruebas. Aquí agrego un matiz que me parece importante para la empresa: cuando la respuesta correcta es una sola (un monto, una fecha, una cláusula, el estado de un pedido), la alucinación no es creatividad, es un error. La diferencia entre un uso y otro no está en el modelo. Está en si tienes cómo detectarla.

El humano cambia de rol. De dar instrucciones detalladas a diseñar el sistema que valida. Pacho lo resume en "arquitectos de sistemas de validación". Es la idea más valiosa de la columna y la que menos se entiende fuera de ingeniería. El resto de este artículo es sobre cómo se ve ese rol cuando no hay pruebas unitarias que correr.

La pregunta que sigue: ¿cuánto cuesta verificar?

En código, el bucle de Pacho se cierra solo por una razón concreta: la verificación es automática y barata. Escribes la prueba una vez, el agente la corre mil veces sin que nadie mire. El "límite infinito" existe porque el costo marginal de verificar es casi cero.

Ahora saca esa misma IA de ingeniería y ponla en el resto de la empresa. Un asistente que redacta propuestas comerciales. Un agente que clasifica tickets. Un sistema que prepara conceptos legales. ¿Quién verifica? ¿Cuánto tarda? ¿Qué pasa si se equivoca? En la mayoría de los procesos de una empresa, la verificación no es una prueba automática. Es una persona leyendo. Y esa persona es el nuevo cuello de botella.

Un ejemplo que he visto más de una vez. Una empresa de servicios automatiza la redacción de cotizaciones. Pasa de escribir veinte por semana a generar doscientas. El equipo comercial está feliz durante dos semanas. En la tercera, el gerente descubre que nadie está revisando las doscientas, que tres salieron con precios de una lista vieja y que un cliente ya aceptó una de ellas. El límite no desapareció. Se movió de escribir a verificar, y nadie lo rediseñó.

Tres tipos de tarea según lo que cuesta verificarlas

No todas las tareas son iguales, y el error más común es tratarlas como si lo fueran. Esta es la clasificación que uso con los equipos. No es teoría: es una forma de decidir dónde el bucle se cierra solo y dónde no.

1. Verificación automática. Existe una fuente de verdad contra la cual comparar, y comparar es barato. Aquí el modelo de Pacho aplica completo: el sistema propone, se verifica, se corrige, y el humano solo ve las excepciones. Ejemplos fuera del código:

• Conciliación. La IA clasifica movimientos bancarios que no cuadraron. La verificación es aritmética: después de la clasificación, el saldo cuadra o no cuadra. Si no cuadra, vuelve a intentar o lo escala.
• Extracción de datos de facturas y pedidos. El total debe coincidir con la suma de las líneas, el NIT debe existir en el registro de proveedores, el número de orden debe existir en el sistema. Tres reglas, ningún humano.
• Respuestas de soporte sobre hechos. "¿Dónde está mi pedido?" se responde consultando el sistema de pedidos. La respuesta se puede verificar contra ese mismo sistema antes de enviarla. Si el modelo inventa una fecha, el verificador la rechaza.
• Reintentos de pagos. Un agente que decide cuándo reintentar una transacción fallida puede verificarse con una regla de idempotencia: nunca dos cobros por la misma orden. Esa regla vive en el código, no en el prompt.

2. Verificación por muestreo. No hay fuente de verdad exacta, pero el costo de un error individual es bajo y el volumen es alto. Una persona revisa una muestra y todas las salidas que el propio sistema marca como dudosas. La métrica que importa es la tasa de error en la muestra, y cuando sube, se cierra el grifo. Ejemplos:

• Clasificación de tickets por tema y urgencia. Se revisa el 5% y todos los que el modelo clasifica con baja confianza.
• Resúmenes de reuniones y síntesis de documentos. Quien estuvo en la reunión lee el resumen en dos minutos; nadie necesita leer la transcripción.
• Borradores de correos comerciales a partir de una plantilla aprobada. Se revisan al azar y se mide cuántos tuvo que corregir el vendedor antes de enviar.

3. Verificación humana obligatoria. El costo de un error es alto, irreversible o reputacional, y no hay forma barata de saber si la salida está bien. Aquí el humano es el bucle y pretender que no lo es produce incidentes. La IA prepara; la persona decide. Ejemplos:

• Un concepto legal sobre un contrato específico.
• La aprobación de un crédito o un reembolso fuera de política.
• Un pago a un proveedor nuevo o un cambio de cuenta bancaria.
• La respuesta a un cliente molesto o a un medio de comunicación.
• Un cambio de precios que afecta a toda una cartera.

Lo interesante es que una misma área tiene tareas de los tres tipos. En soporte al cliente, decir dónde está un pedido es tipo 1, clasificar el ticket es tipo 2 y compensar a un cliente que amenaza con irse es tipo 3. La empresa que trata todo soporte como tipo 3 no automatiza nada. La que lo trata todo como tipo 1 termina en la prensa.

Cómo se ve un sistema de validación fuera de ingeniería

Pacho dice que el nuevo trabajo es diseñar la arquitectura de validación. Para un equipo de software eso significa pruebas, entornos y especificaciones. Para una gerencia significa cuatro piezas, y ninguna requiere escribir código.

Criterio de aceptación escrito antes de la tarea, en términos que se puedan comprobar. No "que la cotización quede bien" sino "usa la lista de precios vigente, no promete fechas de entrega, no supera el descuento autorizado del 10%". Si no puedes escribir el criterio, no puedes delegar la tarea, ni a una IA ni a un practicante.

Una prueba, automática cuando se puede y por muestreo cuando no. Que los precios estén en la lista vigente se comprueba con una regla. Que el tono sea el adecuado se comprueba leyendo una de cada veinte. Las dos cosas son verificación; lo que cambia es el costo.

El humano solo en las excepciones, con registro. El sistema marca lo que no pasó la prueba o lo que no sabe clasificar, y una persona lo resuelve. Cada decisión humana queda registrada, porque esas excepciones son el material con el que vas a afinar el criterio el mes siguiente.

Una métrica y un umbral que apaga el sistema. Tasa de error en la muestra, porcentaje de excepciones, reclamos por salida enviada. Define el número que te haría parar y quién tiene autoridad para parar. Un sistema sin freno no es autónomo, es un riesgo sin dueño.

Vuelve al ejemplo de las cotizaciones con estas cuatro piezas puestas. El criterio está escrito. Una regla rechaza cualquier cotización con un precio fuera de la lista o un descuento fuera de política. Una persona lee una de cada veinte y todas las que la regla rechazó. Si más del 3% de la muestra necesita corrección, el gerente comercial lo sabe el mismo día y frena. Ahora sí puedes pasar de veinte a doscientas sin que el límite se te mueva encima.

Conclusión

Pacho termina su columna con una pregunta: "¿Y tú todavía dudas si implementar o no IA en tu empresa?". Mi respuesta es que la duda correcta no es si implementar. Es dónde, y el criterio es el costo de verificar. En el código, ese costo ya es casi cero, y por eso el desarrollo de software es, como él dice, uno de los usos más naturales de la IA. En el resto de la empresa, ese costo todavía lo pagan personas, y el trabajo del próximo año es bajarlo: escribiendo criterios comprobables, poniendo reglas donde se puede y muestreo donde no, y dejando a los humanos en las excepciones que de verdad lo necesitan.

El límite no es la IA ni la curiosidad del usuario. Es cuánto te cuesta saber si lo que hizo está bien. Cada proceso donde logres que esa respuesta sea "lo comprueba una máquina" es un proceso donde el techo sube de verdad. Ahí sí, como dice Pacho, el límite empieza a parecer infinito.