Su función de IA anda en la demo. ¿Puede probar que funciona en producción?
Una revisión de 10 días hábiles sobre la ingeniería alrededor de una función de IA: qué recupera, qué registra, cuánto cuesta, qué pasa cuando el modelo se equivoca y si los permisos sobreviven a usuarios reales.
Hablar con un ingenieroCuándo sirve esta revisión
- El prototipo responde bien en demos, pero nadie sabe cuán seguido se equivoca.
- Los cambios de prompt salen sin suite de regresión, así que la calidad se mueve por anécdota.
- El sistema responde desde documentos privados, pero los permisos del retrieval no están claros o no se prueban.
- La factura llega antes de que alguien sepa el costo por request, por cliente o por función.
- Se guardan respuestas, pero no las fuentes, el modelo, el prompt o la versión de índice que las produjo.
- Un agente puede llamar tools, pero reintentos, límites y atribución no fueron diseñados como parte del flujo.
Qué revisamos
Calidad del retrieval
Chunking, búsqueda híbrida, ranking, reranking, contexto duplicado y si cada respuesta puede volver a evidencia inspeccionable.
Evaluación
Un set fijo de preguntas, propiedades esperadas, regresiones antes del despliegue, y costo/latencia medidos con cada cambio.
Permisos
Si el retrieval filtra por el usuario antes de que el modelo vea contexto, y si hay pruebas que demuestran esa frontera.
Observabilidad
Versiones de prompt, modelo e índice registradas junto a cada salida, más trazas entre app, retrieval, llamada al modelo y tools.
Costo y latencia
Presupuestos de tokens, oportunidades de ruteo de modelos, caché, peor caso por request y dónde se vuelve visible el gasto.
Comportamiento ante fallas
Timeouts, modelos caídos, falta de evidencia, argumentos inseguros para tools, input malicioso y qué hace el producto en vez de fingir que no pasó nada.
Cómo corre la revisión
Días 1-2: acotar el camino crítico
Elegir el flujo de IA donde equivocarse cuesta más: respuestas a clientes, soporte de decisiones internas, procesamiento documental o acciones de agentes.
Días 3-6: inspeccionar y probar
Leer la implementación, mirar trazas reales cuando existan, ejercitar bordes de permisos y fallas, e identificar qué no se puede probar hoy.
Días 7-9: escribir el informe
Priorizar hallazgos por impacto de negocio y esfuerzo de ingeniería, separando mejoras rápidas de trabajo estructural.
Día 10: traspaso
Recorrer los hallazgos con ingeniería y producto para que el informe se convierta en decisiones, no en un archivo olvidado.
Qué se lleva
- Informe escrito con hallazgos priorizados sobre calidad, privacidad, costo, latencia y operación
- Huecos de evidencia: qué puede probar el sistema hoy y qué no
- Matriz de riesgo para retrieval, permisos, evaluación, observabilidad y acciones de agentes
- Plan de 30 días con mejoras rápidas separadas de trabajo estructural
- Llamada de traspaso con quienes van a actuar sobre los hallazgos
Preguntas que nos hacen
¿Esto es prompt tuning?
No. Ajustar prompts puede ser una recomendación, pero la revisión mira readiness de producción: retrieval, evaluación, permisos, costo, latencia, observabilidad y caminos de falla.
¿Necesitan acceso de escritura a producción?
No. La revisión está pensada con acceso de solo lectura, código fuente, contexto de arquitectura, tableros y conversaciones con los ingenieros que conocen el sistema.
¿Y si la función todavía es prototipo?
Suele ser el momento más barato para revisarla. Si registros, permisos y evaluación se diseñan antes de lanzar, son decisiones. Agregados después, son migraciones.
¿Pueden implementar las correcciones después?
Sí, si hay encaje y disponibilidad. El informe sigue siendo suyo igual: puede ejecutarlo su equipo, otro proveedor o Devsitia.
Iniciar una conversación
Cuéntenos qué están construyendo, o qué se está rompiendo. Va a recibir una respuesta directa de un ingeniero, no un libreto de ventas.