Implementación de IA · Granada / Remoto

Implementación técnica de IA

Ya sabes qué quieres construir. Esta fase consiste en escribirlo con calidad de producción: integrado en tu stack, con tests, evals automatizadas, observabilidad y coste bajo control. Empiezo por cómo vamos a medir que funciona y termino con una operación que tu equipo pueda sostener sin mí.

Este es el servicio para cuando la decisión ya está tomada —porque venimos de la fase de diseño, porque un piloto demostró que la idea funciona o porque simplemente lo tienes claro— y falta construirlo de verdad. Me incorporo a tu repositorio, tu CI y tus revisiones de código, y trabajo con las convenciones que ya tienes.

La distancia entre una demo y un sistema en producción se mide en las cosas que la demo no hace: manejar el error del proveedor a las tres de la madrugada, no gastarse el presupuesto del mes en una tarde, responder en menos de dos segundos, versionar los prompts para saber qué cambió cuando la calidad baja, y tener un test que lo detecte antes de que lo note un usuario. Esa distancia es la mayor parte del trabajo, y es justo la que casi nunca se presupuesta.

  • Encaja si ya tienes claro qué construir y necesitas a alguien que lo escriba con el mismo estándar que el resto de tu código.
  • Encaja si tu equipo domina producto y backend pero es la primera vez que pone un LLM en el camino crítico de un usuario.
  • Encaja si tienes un prototipo que funciona en un notebook y hay que convertirlo en un servicio que alguien pueda operar y mantener.
  • Encaja si necesitas refuerzo temporal con criterio: entro, construimos, documentamos y tu equipo se queda con ello.
  • No encaja si todavía no está claro qué problema resuelve el sistema ni cómo medirás si funciona. Empezar a construir ahí sale caro; para eso está la fase de diseño.
  • No encaja si buscas un equipo entero para varios frentes a la vez: trabajo solo, y eso limita el ancho de banda a un proyecto con foco.
Desarrollo integrado en tu stack

Dentro de tu aplicación si es Rails o Python, o como servicio independiente detrás de una API si tu stack es otro. Con tus convenciones, tu estilo de código y pull requests que alguien de tu equipo pueda revisar de verdad.

Suite de evals automatizada

Un conjunto de casos con resultado esperado que se ejecuta en cada cambio de prompt, de modelo o de parámetro. Sin esto, ajustar un prompt es una apuesta; con esto, es un cambio con un número antes y otro después.

Tests y CI

Tests unitarios y de integración con las llamadas al modelo simuladas, para que la suite sea rápida y determinista, más una capa de pruebas contra el proveedor real que se ejecuta aparte. Todo dentro de tu pipeline.

Observabilidad

Trazas de cada operación con su prompt, su respuesta y su latencia; coste por operación; alertas cuando la calidad o el gasto se salen de rango. Cuando algo falle, sabrás qué paso falló y con qué entrada.

Control de coste y latencia

Caché donde tenga sentido, modelo pequeño para las tareas que no necesitan el grande, límites por usuario y respuestas en streaming. El coste es una decisión de arquitectura y se toma mientras se construye.

Despliegue y handover documentado

Puesta en producción, documentación de operación y una sesión de traspaso con tu equipo: cómo se cambia un prompt, cómo se añade un caso a los evals, qué mirar cuando algo va mal. Que puedas seguir sin mí forma parte del encargo.

En un sistema de IA en producción, la llamada al modelo es la parte pequeña. Lo que cuesta son las colas, los reintentos, la idempotencia, los permisos y el control del gasto: ingeniería de backend de siempre con una fuente nueva de incertidumbre encima, y ahí se apoyan mis más de diez años construyendo APIs y sistemas a escala. En la práctica se concreta en tres cosas que llevo a todos los proyectos. Los prompts viven versionados en el repositorio como cualquier otro código, con su historial y su revisión. La suite de evals se ejecuta en GitHub Actions con cada pull request, así que un cambio que empeora la calidad se ve antes de fusionarlo. Y las trazas, la latencia y el coste por operación se instrumentan en el primer despliegue, antes de que hagan falta.

Ruby on RailsPythonFastAPIClaude APIOpenAI APIPostgreSQLpgvectorDockerGitHub ActionsEvals
01
Arranque técnico

Accesos, entorno, lectura del código existente y acuerdo sobre alcance, criterios de aceptación y qué significa «terminado» en este proyecto. Una semana, casi siempre limitada por los permisos y no por el trabajo.

02
Construcción por iteraciones

Ciclos cortos con algo desplegable en cada uno y una demo cada semana. Los evals se escriben a la vez que el código, no al final. El rango es amplio a propósito: cuatro semanas para una funcionalidad acotada, diez o más si hay varias integraciones de por medio.

03
Endurecimiento

Carga, caídas del proveedor, casos límite, latencia, presupuesto y alertas. Aquí se decide si el sistema aguanta un lunes por la mañana. De dos a tres semanas antes de abrirlo a todo el mundo.

04
Handover y acompañamiento

Documentación, sesión de traspaso y un periodo de acompañamiento acordado para las primeras semanas en producción. Después tu equipo lleva el sistema; yo sigo disponible si aparece algo que requiera el contexto original.

Cuéntame tu caso y te digo con franqueza si la IA es la herramienta adecuada — y cómo la implementaría.