Qué es una compañía AI-native

Compañía AI-native

Una compañía AI-native es aquella cuya operación fue diseñada desde su origen para que la inteligencia artificial, el software, los datos, los workflows, los agents, la automatización, los sistemas deterministas, las integraciones y las personas formen parte de un único sistema operativo empresarial, en lugar de ser herramientas añadidas sobre procesos que ya existían.

La palabra que hace el trabajo en esa definición es «diseñada». No se trata de cuánta IA usa una empresa, sino de si su operación existiría en esa forma sin ella. Si al quitar la IA la empresa sigue funcionando igual, con más lentitud, entonces la IA era una mejora. Si al quitarla el proceso deja de tener sentido, el proceso era AI-native.

Qué NO es una compañía AI-native

El término se está usando para casi cualquier cosa, y eso lo vacía. Cuatro confusiones frecuentes:

• No es «una empresa con agentes». Los agents son una capa de la operación, no la definición. Una empresa puede tener veinte agentes corriendo sobre procesos que siguen siendo los de antes.
• No es una empresa que vende IA. Vender inteligencia artificial y operar con ella son cosas distintas, y hay compañías de IA cuya propia operación interna es completamente manual.
• No es haber adoptado ChatGPT. Que un equipo use un asistente para redactar más rápido es productividad individual, no diseño organizacional.
• No es ausencia de personas. Es lo contrario: obliga a decidir explícitamente qué se queda en manos humanas, en vez de dejar que lo decida el presupuesto.

En qué se diferencia de la transformación digital

La transformación digital tomó procesos analógicos y los movió a software. La empresa siguió siendo la misma, con los mismos pasos, en una interfaz distinta. Ser AI-native no es el siguiente escalón de eso: es una pregunta diferente. No «cómo digitalizo este proceso», sino «si tuviera estas capacidades desde el primer día, ¿existiría este proceso?».

Cómo se estructura: Workflows, Agents, Tools

Una operación AI-native necesita un vocabulario para no convertirse en una colección de automatizaciones sueltas que nadie puede auditar. El que uso tiene tres capas, y la disciplina está en no agregar una cuarta.

Workflows

Un workflow es un proceso reproducible que convierte una entrada en un resultado. Para contar como tal debe poder describirse con siete cosas: propósito, disparador, entrada, pasos, herramientas que usa, qué pasa cuando falla, y cómo se valida el resultado. Si un proceso no se puede escribir así, todavía no está listo para automatizarse, y ese es el hallazgo, no un obstáculo.

Agents

Un agent es un sistema de IA que inspecciona, razona, propone o ejecuta dentro de permisos explícitos. Cada uno necesita rol, alcance, herramientas permitidas, acciones prohibidas, entradas, salidas y una regla de escalamiento: qué hace cuando no está seguro. Un agente sin acciones prohibidas escritas no tiene autonomía, tiene ausencia de límites, que es una cosa distinta y más cara.

Tools

Las tools son los servicios, APIs, scripts y librerías que usan los workflows y los agents. Cada una documenta su propósito, su interfaz, su modelo de autenticación y su comportamiento ante el error. La mayor parte del riesgo operativo de una compañía AI-native no vive en el modelo: vive en qué pasa cuando una herramienta responde tarde, responde mal, o no responde.

Human gates: la parte que no se automatiza

Un human gate es un punto del workflow donde una persona tiene que aprobar antes de continuar. No es un residuo de desconfianza en la tecnología: es una decisión de diseño sobre dónde el costo de equivocarse es asimétrico.

El criterio que uso es simple: si el error es reversible y barato, se automatiza; si es público, afecta el dinero de otra persona, o compromete a la empresa con un tercero, pasa por una persona. La velocidad que da el sistema es justamente lo que hace peligroso no tener esos puntos: un sistema que puede publicar sin supervisión puede equivocarse a la velocidad a la que produce.

Los límites reales

Cuatro cosas que en la práctica no funcionan como se promete, y que conviene saber antes y no después:

• Los procesos que nadie había escrito no se automatizan: se descubren. La mayor parte del trabajo inicial no es técnica, es escribir por primera vez lo que la empresa venía haciendo de memoria.
• Un sistema que produce mucho necesita más revisión, no menos. El cuello de botella se mueve de producir a verificar, y si nadie planeó esa capacidad, el sistema se atasca ahí.
• La calidad de los datos internos limita todo lo demás. Ninguna arquitectura compensa registros incompletos o que nadie mantiene.
• Las integraciones con sistemas de terceros son el punto frágil. El modelo rara vez es lo que falla; falla la API que cambió sin avisar.

Cómo empezar

• Escribir un proceso completo, de punta a punta, como si se lo fuera a explicar a alguien que llega mañana. La mayoría de las empresas descubre aquí que el proceso no existía: existían las personas que lo hacían.
• Marcar en ese proceso dónde está cada decisión, y quién la toma hoy.
• Separar las decisiones reversibles y baratas de las que no lo son. Ese corte es el mapa de los human gates.
• Automatizar solo la parte reversible, con validación, y medir qué pasa cuando falla, no cuando funciona.
• Recién entonces preguntarse qué se podría hacer que antes no era posible. Esa pregunta, hecha antes de los cuatro pasos anteriores, produce demos y no operación.