Software AI-native: por qué tu próxima plataforma debe construirse alrededor de la inteligencia

Muchas empresas respondieron a la IA generativa con lo que tenían a la mano: un chatbot en el portal, un botón de “resumir” en el CRM. Tenía sentido. Había que mostrar algo y eso se entrega rápido.

El problema aparece después, cuando toca planear la siguiente plataforma. Un sistema que se construye este año va a operar mucho tiempo, y los modelos van a cambiar varias veces en ese lapso. Si la arquitectura trata a la IA como accesorio, cada mejora futura costará como un proyecto nuevo.

Un caso que se repite

Piensa en un portal interno de compras. El historial de cada proveedor vive en el ERP y buena parte de las reglas de negocio está escondida en pantallas y procedimientos almacenados.

Alguien agrega un asistente que resume cada solicitud. En la demo funciona. En producción no ve el historial del proveedor, así que omite justo lo que el aprobador necesita. Meses después, compras pide que un agente arme la orden a partir del correo del proveedor. Ahí el equipo descubre que no hay forma segura de que el agente ejecute esa acción: los permisos están amarrados a la interfaz y la lógica nunca se expuso como servicio.

Nadie hizo nada mal. El sistema se diseñó para personas frente a una pantalla.

“El sistema se diseñó para personas frente a una pantalla.”

Qué significa diseñar AI-native

En una plataforma AI-native, la inteligencia se trata como una capacidad estructural, al nivel de la seguridad o del modelo de datos. Eso obliga a resolver temprano asuntos que en un proyecto tradicional ni aparecen en la agenda:

• Cómo organizar el contexto del negocio para que un modelo lo consulte con los permisos del usuario.
• Qué acciones del sistema se exponen como herramientas, para personas y para agentes, y con qué límites.
• Cómo se evalúa la calidad de las respuestas antes de cada liberación, igual que hoy se prueba el código.
• Cómo cambiar de proveedor de modelos sin reescribir media plataforma.

Ninguna es exótica. Lo caro es decidirlas tarde. Reorganizar permisos o separar lógica e interfaz con el sistema en producción implica migraciones y meses de trabajo que nadie presupuestó.

“

Lo caro es decidirlas tarde.

No hace falta empezar de cero

Esto tampoco significa tirar lo que ya funciona. Lo difícil es escoger el primer proyecto de modo que deje bases reutilizables, como un catálogo de herramientas con permisos claros o una capa de contexto que otros equipos puedan aprovechar. Un mal punto de partida deja otro piloto aislado. Uno bueno abarata el segundo proyecto.