De una frase a objetos, vistas, permisos y Agents: la cadena de generación de AI Builder
Lo importante de AI Builder no es convertir una frase en páginas, sino descomponer una necesidad de negocio en objetos, campos, vistas, flujos, permisos, automatizaciones y herramientas de Agent.
En resumen: un buen AI Builder no convierte una frase en unas cuantas páginas; descompone una necesidad de negocio en objetos, campos, vistas, flujos, permisos y herramientas de Agent —una especificación de aplicación ejecutable, modificable y gobernable—.
“Generar una aplicación desde una frase” suena poderoso, pero puede engañar.
Si el lector imagina que un prompt solo crea unas páginas, no hay mucha diferencia con una demo de generación de código. La pregunta importante es cómo AI Builder descompone una necesidad de negocio en metadatos de aplicación que puedan ejecutarse, modificarse y gobernarse.
Ejemplo:
Ayúdame a crear una aplicación de riesgo de proveedores. Debe gestionar proveedores, certificaciones, cotizaciones, órdenes de compra, entregas y problemas de calidad. AI debe detectar certificaciones vencidas, cotizaciones anómalas y riesgo de entrega. Los proveedores críticos con alto riesgo deben requerir aprobación del gerente de compras.
La pregunta real es: ¿qué ocurre con esa frase dentro de la plataforma?
Primer paso: generar un grafo de objetos
AI Builder debe identificar los sustantivos del dominio.
No es una sola tabla de proveedores. Es un conjunto de objetos relacionados: supplier, supplier_qualification, quotation, purchase_order, delivery_record, quality_issue, supplier_risk y approval_task.
Esta separación importa porque define los límites de la aplicación. Si todo vive en una tabla grande, será difícil explicar qué entrega, cotización o certificación causó un riesgo. Con objetos claros, el riesgo se conecta con evidencia, la aprobación con razones y el Agent puede explicar su base.
Segundo paso: campos y relaciones con significado
Un generador débil trata los campos como inputs de formulario. Un buen Builder los trata como semántica de negocio.
Una certificación no es solo un archivo adjunto. Necesita tipo, número, fecha de inicio, vencimiento, estado de revisión, revisor, proveedor relacionado y si es crítica.
Una cotización no es solo un importe. Necesita material, cantidad, precio unitario, vigencia, desviación frente al histórico, transporte, servicio y solicitud de compra relacionada.
Las relaciones también son claves. Un proveedor tiene muchas certificaciones, cotizaciones, órdenes, entregas y problemas de calidad. Un riesgo debe apuntar a esas evidencias.
Así, el análisis de AI no es una suposición del modelo, sino una explicación basada en relaciones de objetos.
Tercer paso: vistas para cada rol
Una aplicación empresarial no muestra la misma tabla a todos.
| Rol | Vistas |
|---|---|
| Comprador | Mis proveedores, certificaciones pendientes, comparación de cotizaciones |
| Gerente de compras | Proveedores de alto riesgo, aprobaciones pendientes, riesgo de materiales críticos |
| Calidad | Problemas recientes, defectos repetidos, estado de corrección |
| Legal / compliance | Brechas de certificación, riesgo contractual, lista negra |
| Dirección | Distribución de riesgo, concentración de proveedores, tendencias de compra |
Esto se parece a configurar vistas en low-code. La diferencia es que AI Builder genera un punto de partida razonable desde la necesidad de negocio.
Cuarto paso: permisos y límites de acción
Los permisos suelen ignorarse en demos, pero distinguen una plataforma profesional.
En esta aplicación:
- compras mantiene perfiles, pero no cambia conclusiones de calidad;
- calidad cierra problemas, pero no aprueba órdenes;
- gerentes aprueban compras de alto riesgo;
- usuarios normales no ven datos financieros sensibles;
- AI puede sugerir riesgo, pero no bloquear automáticamente un proveedor;
- acciones de alto riesgo requieren aprobación.
Son reglas de runtime, no detalles de página.
Si un Agent recibe “encuentra proveedores de alto riesgo y pausa compras”, debe operar dentro de esos límites.
Quinto paso: flujos, automatización y SLA
Los objetos estáticos no bastan. La aplicación debe mover trabajo.
El proceso puede incluir alta de proveedor, carga de certificaciones, revisión de AI, comparación de cotizaciones, creación de orden, registro de entrega, detección de riesgo, aprobación, sugerencias de corrección y cierre con auditoría.
La automatización también debe generarse:
- recordar 30 días antes del vencimiento;
- bloquear compras cuando una certificación crítica venció;
- crear riesgo cuando baja la puntualidad;
- crear revisión ante problemas repetidos;
- recordar aprobaciones vencidas.
Eso es generar una aplicación, no páginas.
Sexto paso: herramientas de Agent
La capa final es el tooling del Agent.
La plataforma debe generar herramientas gobernadas: consultar riesgo, comparar cotizaciones, explicar fuentes de riesgo, crear tareas de revisión, iniciar aprobación y generar reportes mensuales.
Cada herramienta necesita entradas, salidas, permisos y auditoría.
Cuando alguien pregunta si todavía puede comprar a un proveedor, el Agent debe consultar datos, certificaciones, entregas, calidad y cotizaciones, y devolver una conclusión con evidencia. Las acciones críticas deben pasar por acciones de plataforma.
Un buen Builder muestra un plan
AI Builder debe crear confianza. No debe generar todo en silencio. Debe mostrar:
- objetos a crear;
- campos clave;
- relaciones;
- vistas;
- permisos;
- automatizaciones;
- herramientas de Agent;
- acciones que requieren confirmación humana.
Solo después de confirmar se genera la aplicación. El Builder es un arquitecto colaborativo, no una caja negra.
La cadena de ObjectStack
ObjectStack debería convertir lenguaje natural en una especificación de aplicación que impulse la runtime:
Necesidad en lenguaje natural → objetos de negocio → campos y relaciones → vistas y formularios → límites de permiso → automatización de flujo → herramientas de Agent → runtime auditada
El valor no es magia. Es saber a qué capa de metadatos pertenece cada frase y cómo esas capas construyen un sistema de negocio ejecutable.