La demo funcionaba. Producción es otra conversación.
Un PoC de IA demuestra que la idea es posible. No demuestra que aguante los datos del cliente, sus permisos, su volumen ni su revisión de seguridad. Esta es la lista de lo que suele faltar, escrita para que puedas usarla como checklist aunque no nos llames.
Si el proyecto es de un cliente tuyo, mira cómo trabajamos con consultorasLo que casi siempre falta
- 01
No hay forma de saber si responde bien
Sin evaluaciones automatizadas, la calidad se juzga probando a mano y recordando. Cada cambio de prompt, de modelo o de datos es una apuesta. Hacen falta casos de prueba con respuesta esperada, ejecutados en cada cambio, y un umbral por debajo del cual no se despliega.
- 02
Nadie puede explicar una respuesta concreta
Cuando el cliente pregunta por qué el agente dijo algo, hay que poder reconstruirlo: qué se recuperó, con qué permisos, qué prompt se envió, qué versión de modelo respondió. Sin esa traza no hay auditoría posible ni forma de corregir la causa.
- 03
Los permisos del PoC no son los del cliente
Un prototipo suele leer todo el corpus. En producción, dos usuarios distintos tienen que ver cosas distintas, y el filtrado tiene que ocurrir en la recuperación, no en el prompt. Es el punto donde más proyectos se atascan en la revisión de seguridad.
- 04
No hay techo de gasto ni de latencia
El coste por tarea y el tiempo de respuesta no se miden hasta que alguien los paga o los sufre. Hacen falta límites, alertas y una decisión explícita sobre qué se degrada cuando se alcanzan.
- 05
No se puede volver atrás
Si el despliegue no es reproducible y no hay rollback, cada cambio es irreversible en la práctica. Infraestructura descrita en código sobre Azure, entornos separados y una vía de vuelta probada.
- 06
Se equivoca solo, sin red
Donde equivocarse cuesta dinero o reputación, la decisión la aprueba una persona. Definir dónde está esa frontera es una decisión de negocio, no técnica, y conviene tomarla antes de abrir el sistema.
Llévatela y úsala aunque no nos llames: la versión impresa recoge los seis puntos con espacio para anotar cuál tienes resuelto.
Lo que tu cliente va a preguntar antes de dejarnos entrar.
Cuando el proyecto es de un cliente final, alguien de su equipo de seguridad va a revisar esto. Lo tenemos escrito antes de empezar para que puedas enseñarlo en vez de improvisarlo.
-
Accesos mínimos y entornos acordados
Trabajamos con los permisos justos para la pieza que nos toca y en los entornos que acordemos. Nada de credenciales compartidas ni accesos abiertos «para ir más rápido».
-
Los permisos del cliente se aplican en la recuperación
Dos usuarios distintos ven cosas distintas, y el filtrado ocurre al recuperar los datos, no confiando en el prompt. Es el punto donde más proyectos se atascan en la revisión de seguridad.
-
Cada respuesta se puede reconstruir
Qué se recuperó, con qué permisos, qué prompt se envió y qué versión de modelo respondió. Sin esa traza no hay auditoría posible ni forma de corregir la causa.
-
Qué datos tocan las herramientas de IA, por escrito
Si intervienen modelos de terceros, dejamos definido antes qué datos pueden usarse, dónde y con qué límites, en un formato que puedes trasladar a la seguridad de tu cliente.
-
Guardrails y control humano donde cuesta dinero
Límites de coste y latencia con alertas, y una frontera explícita: dónde el agente decide solo y dónde lo aprueba una persona. Esa frontera es una decisión de negocio y se toma antes de abrir el sistema.
-
Confidencialidad y no-circumvention firmados
NDA antes de contarnos el detalle si lo necesitas, y no-circumvention por escrito: no vendemos nada a tu cliente por nuestra cuenta, ni durante el proyecto ni después.
-
El código es tuyo desde el primer día
Vive en los repositorios que digas, no en los nuestros. Al cerrar quedan runbooks, informe de evaluaciones y sesiones de transferencia: no dependes de nosotros para operar lo entregado.
Si tu cliente exige una homologación concreta o un partner oficial determinado, dínoslo en la primera llamada: es mejor saberlo entonces que a mitad del proyecto.
Cómo lo abordamos
No empezamos de cero. Revisamos lo que existe, decimos qué se conserva y qué se reescribe, y cerramos alcance por hitos con criterios de aceptación escritos antes de empezar. Si el enfoque de base no aguanta, lo decimos antes de firmar y no a mitad del proyecto.
Cuéntanos qué está construido, con qué datos y para cuándo tiene que estar en producción. En 30 minutos te devolvemos un mapa de riesgos y una opinión clara sobre qué falta.
Tres entregas, con contexto y resultado¿Hablamos de tu proyecto?
En 30 minutos revisamos qué quieres construir o qué tienes ya en marcha, los datos, las integraciones y lo que falta para que aguante cuando entren los usuarios. Da igual si el proyecto es tuyo o de un cliente tuyo: la llamada es la misma.
Revisión gratuita de 30 min, sin compromiso. Firmamos NDA antes si lo necesitas. Respondemos en el siguiente día laborable.