IA en producción
Desarrollo con IA: su primer flujo en producción, en 21 días
Metemos la IA dentro de los sistemas que ya llevan su negocio. Un runtime de agente en Go, herramientas tipadas hacia su ERP, su CRM, su cola de tickets y su mainframe, un paso de aprobación en todo lo que escribe y una suite de evaluaciones en CI que tumba la compilación cuando las respuestas empeoran. Cualquier stack, cualquier sector, desde un flujo suelto hasta una plataforma que operan sus propios ingenieros.
21 días hasta el primer flujo en producción
La fila tachada es la parte que se salta casi todo piloto, y sin ella nadie puede decir si el modelo empeoró la semana pasada.
Prototipo
Un notebook que funciona con datos de demo y una API cerrada de un proveedor.
- spec.docxWord
- proof-of-conceptPython · notebook
- vendor APIclosed
- evalnone
Producción
Un servicio con herramientas que puede llamar, pruebas que puede suspender y trazas que puede buscar.
- agent runtimeGo
- tool layerTypeScript
- eval harnessCI gate
- tracesOpenTelemetry
21 días hasta el primer flujo en producción
Cómo va el trabajo
- 01días 1–2
Elegir un flujo
Un proceso con volumen y con respuesta correcta. Medimos lo que le cuesta hoy en minutos y en errores, porque contra esa cifra se va a juzgar el resultado.
- 02días 2–6
Montar primero el conjunto de evaluación
Unos cientos de casos reales de su propio histórico, cada uno con la respuesta que dio su gente. Es la parte poco lucida del proyecto y la razón de que todo lo que viene después se pueda demostrar en vez de discutir.
- 03días 5–16
Construir el runtime y las herramientas
Runtime de agente en Go, adaptadores tipados hacia sus sistemas, un paso de aprobación en todo lo que escribe. Las evaluaciones corren en cada commit desde el primer día.
- 04días 14–21
Ponerlo en marcha y entregarlo
Trazas, un runbook y una jornada con sus ingenieros para que cambien prompts y herramientas sin llamarnos. La entrega va dentro del precio.
Qué hace la plataforma y qué hace una persona
| Qué hace la plataforma y qué hace una persona | Quién hace qué | Notas |
|---|---|---|
| Leer el código y encontrar los puntos de integración | Plataforma | Horas sobre un repositorio que una persona tardaría una semana en leer. |
| Elegir qué flujo va primero | Ingeniero | Volumen, una respuesta comprobable y alguien de su lado que responda por el resultado. |
| Escribir los adaptadores hacia sus API | Los dos | La plataforma redacta a partir del contrato de la API. Una persona arregla aquello sobre lo que el contrato mentía. |
| Montar el conjunto de evaluación con su histórico | Los dos | Sacar los casos es automático. Decidir qué respuestas pasadas eran correctas no lo es. |
| Pasar las regresiones en cada commit | Plataforma | Una caída tumba la compilación, igual que una prueba unitaria rota. |
| Decidir en qué puede escribir el agente | Ingeniero | Su riesgo, su decisión, por escrito antes de que corra nada. |
Quién va a estar en el proyecto
Decenas de migraciones detrás y más de diez años metidos en sistemas ajenos. Los ingenieros que han puesto servicios en Go y TypeScript en producción al lado de COBOL, RPG, VB6, Delphi y PHP son los mismos que construyen la capa de agente. Por eso nuestra IA acaba dentro de los sistemas que mueven su dinero y no al lado de ellos.
Denos acceso de lectura y en unos días la plataforma saca el mapa de módulos y la lista de código muerto de su propio sistema. El documento se lo queda nos contrate o no, y es la forma más rápida de ver cómo trabajamos.
Preguntas que nos hacen los ingenieros
- ¿Esto es un envoltorio sobre una API de chat?
- Hay un modelo dentro, igual que hay una base de datos dentro de su sistema de facturación. El trabajo es la capa de herramientas, los puntos de aprobación y las evaluaciones que le dicen cuándo una actualización del modelo ha empeorado las cosas. Llamar a una API es la parte barata; saber cuándo la respuesta está mal es lo que está pagando.
- ¿Qué pasa cuando el modelo cambia bajo nuestros pies?
- La suite de evaluaciones corre contra el modelo candidato antes de cambiar nada. Si la puntuación baja, se queda en el anterior hasta que los prompts y las herramientas se pongan al día.
- ¿Dónde corre nuestro código mientras trabajan con él?
- Donde usted exija, incluido enteramente dentro de su propia red o de su cuenta de nube. Hemos trabajado bajo VPN de cliente, en máquinas de compilación aisladas y sobre hardware que no salió nunca del edificio; el detalle va en el contrato.
- ¿De quién es lo que construyen?
- Suyo. Repositorios de Go y TypeScript normales, librerías normales, ninguna llamada a nosotros en tiempo de ejecución. Nuestra plataforma es cómo trabajamos, no algo que usted acabe alquilando.
- ¿Podrá mantenerlo nuestro equipo cuando terminen?
- Para eso está la entrega, y por eso la capa de herramientas es tipada y los prompts viven en control de versiones y no en la consola de un proveedor. Sus ingenieros cambian la definición de una herramienta, vuelven a pasar las evaluaciones y publican, sin nosotros en la sala.
Mándenos el flujo
Señale el proceso que automatizaría primero y lo que le cuesta más o menos cuando sale mal. Le devolvemos cómo lo construiríamos, cuánto tarda y cuánto cuesta, en dos días laborables.
Cuatro pantallas: el sistema, qué duele, dónde quiere acabar y cómo localizarle. No se agenda ninguna llamada salvo que la pida.