Hoy todo el mundo vende software con IA, apps con IA, automatizaciones con IA. La demanda está. El problema no es usarla. Es usarla encima de un producto que no aguanta: datos sucios, permisos improvisados, flujos que nadie puede explicar. La capa sale en la demo. El sistema, en el incidente.
La IA no es un atajo: es una capa real, y hay que hacerla bien. Bien hecha va después de un producto que ya tiene datos, permisos y un flujo que funciona sin modelo. El software antes de meter IA es ese suelo. Truman no discute la capa. Construye lo de debajo para que escale. El orden no es ideología. Es criterio.
Este artículo es ese orden. Qué tiene que estar listo en tu software o desarrollo web a medida antes de poner un modelo encima. Sin ir contra la herramienta. Sin vender la capa como oferta del estudio. Con el suelo que, si falta, cualquier capa se cae —por muy bien que suene el prompt.
Por qué el software antes de meter IA no es un freno
El orden no va contra el mundo. Va a favor de que la capa funcione. Un modelo sobre un sistema sólido resume bien, sugiere con contexto y se puede auditar. Un modelo sobre un Excel, un WordPress lleno de plugins y un login con isAdmin produce teatro: una caja de chat que alucina precios y enseña facturas ajenas.
En Truman construimos producto, web y software a medida. La IA aparece como capacidad que existe y como contrapunto de orden: primero el sistema que aguanta, después la capa. No la vendemos como servicio del estudio. No te vamos a proponer una home «con modelo» como oferta. Si tu pregunta es cómo hacerla bien, la respuesta empieza por el software, no por el proveedor del modelo.
Los límites de la capa generativa en un proyecto web — qué puede escribir, qué no puede firmar, dónde el oficio sigue siendo innegociable— están en IA generativa en desarrollo web: límites. Este artículo va un paso antes: el suelo. Sin suelo, el debate sobre el modelo es ruido.
Datos: origen, dueño y una verdad
Antes de un modelo, el dato tiene que existir en un sitio que el producto controle. No en cinco Excels, tres CRMs y un correo de «la versión buena». Origen, esquema, quién lo escribe, qué pasa si hay conflicto. Si no puedes señalar la fuente de un pedido, un cliente o un evento, no tienes base para una capa que «responda sobre tu negocio».
En Klapper —plataforma propia de entradas— el producto aguanta porque el evento, el aforo, el pedido y el usuario son un modelo, no un export. Una capa de recomendaciones o de soporte tendría, si algún día se diseña, algo debajo: stock, estados, historial. En EIM Jeanología el contexto es industrial: el dato de planta no admite una caja que «adivine». Primero el flujo y el registro. La inteligencia, si entra, entra encima.
| Señal en el software | Listo para una capa | Todavía no |
|---|---|---|
| Una fuente por entidad | Pedido, cliente, evento | Tres hojas y un «pregunta a María» |
| Dueño del dato | Quién escribe, quién lee | Todo el mundo edita el mismo campo |
| Historial | Se puede auditar un cambio | Overwrite sin rastro |
| Calidad mínima | Campos obligatorios reales | El 40% vacío o en notas libres |
| API o exportación estable | Contrato de datos | Capturas de pantalla y CSV a mano |
No hace falta un data lake. Hace falta una verdad por entidad y la honestidad de no mandar al modelo lo que no fiarías a un junior. La capa bien hecha consume un contrato. Si el contrato no existe, lo primero es software, no un plugin de «AI search».
Permisos: quién puede ver qué (también la capa)
Un modelo no inventa autorización. Hereda la que tengas — o la ausencia. Si el producto no distingue comercial, admin y cliente, el asistente tampoco. El error clásico es enchufar un chat a la base y descubrir que resume contratos de otro tenant. Eso no es un fallo de IA. Es un fallo de roles que la capa hace visible.
Autenticación y autorización se diseñan antes de las pantallas bonitas y mucho antes de un copilot. Los errores que más caros salen —un isAdmin, un rol string, un if en cada controlador— están desglosados en autenticación y roles de usuario. Si esa casa no está, no metas un modelo que recorra documentos. Primero el perímetro.
Flujos que ya funcionan sin modelo
La capa bien hecha acelera un flujo que existe. No lo inventa. Si el alta de un cliente, el parte de planta o la reserva de aforo no se pueden completar a mano de forma fiable, un asistente no lo va a «arreglar». Va a automatizar el apaño. Primero el proceso en el producto: estados, validaciones, siguiente paso. Después, si tiene sentido, sugerir, resumir o clasificar encima.
Si apagas el modelo mañana, ¿el software sigue dejando vender, reservar o registrar —o se cae el proceso entero?
Un producto que ya aguanta (deuda, no teatro)
«Aguanta» no es un slogan. Es que el sistema se puede desplegar, observar y cambiar sin miedo. Si cada feature nueva es un milagro, una capa de IA es otra hipoteca: más coste, más superficie, más incidente opaco. La deuda técnica que impide evolucionar — y que hay que nombrar antes de añadir complejidad— está en deuda técnica en la web.
Aguanta también quiere decir: entornos, backups, identidad, un CMS o un panel que alguien interno puede usar. En Truman eso es la oferta. Software a medida, web, producto, sistemas. La capa de IA se diseña cuando ese suelo existe, no como primer ladrillo de un pitch. Quien la haga —vosotros u otro— podrá hacerla bien. Quien la ponga antes, pagará dos veces: la capa improvisada y el sistema que no se construyó.
Cuidado con el orden invertido: no es la herramienta. El error es usar la capa para tapar un producto que no cierra. La IA, bien hecha, es una capa encima de un sistema que ya escala. Ese matiz importa. No vamos contra la herramienta. Vamos contra poner el modelo donde aún no hay software.
El orden para hacerla bien
No hay un checklist universal de «ya puedes contratar un modelo». Hay un umbral por producto. Este es el que pedimos ver —como estudio que construye la base— antes de que alguien, quien sea, ponga una capa encima.
No vamos contra la IA. Hay que hacerla bien, encima de un sistema que ya aguanta. Si el producto no tiene datos, permisos ni un flujo que se pueda nombrar, no te falta un modelo. Te falta software.
Antes de meter una capa de IA
- ¿El flujo principal se puede terminar hoy sin ningún modelo?
- ¿Cada entidad crítica (cliente, pedido, evento, parte) tiene una fuente y un dueño?
- ¿Hay historial de cambios, o el dato se pisa sin rastro?
- ¿Los roles existen de verdad y la capa no tendría un bypass?
- ¿Podrías auditar qué se envió a un modelo y qué se mostró al usuario?
- ¿El proceso que quieres «inteligizar» está escrito en el producto, no solo en la cabeza de tres personas?
- ¿La deuda técnica te deja desplegar y observar, o cada cambio es un milagro?
- ¿La pregunta de negocio es un paso concreto a acelerar —o «tener IA» en el pitch?
Preguntas frecuentes sobre el software antes de meter IA
¿Qué tiene que estar listo en el software antes de meter IA?
Un flujo que cierra sin modelo, datos con origen y dueño, permisos que se pueden heredar y un producto que se puede operar y desplegar. La capa va encima de eso. Si falta, el siguiente paso es software, no un proveedor.
¿Truman ofrece la capa de IA como servicio?
Truman construye la base: web a medida, producto, sistemas que aguantan. No vendemos la capa como servicio del estudio. Si esa capa tiene sentido, tiene que apoyarse en ese suelo. El orden es el criterio, no una oferta de modelos.
¿Se puede empezar por un piloto de IA y el software después?
Un piloto sobre datos controlados y un flujo ya existente puede valer. Un piloto que sustituye al producto no. Si el piloto necesita inventar usuarios, permisos y origen de datos, no es un piloto de capa: es un prototipo de sistema. Empieza por el sistema.
¿Hay que ir contra la IA?
No. Es una capa real y hay que hacerla bien. El error es usarla para tapar un software que no aguanta. El problema no es la herramienta. Es el orden invertido: modelo primero, producto después.
