Servicio
Servicios de integración de IA
Colocada donde elimina trabajo, no donde luce bien.
Para equipos que quieren IA dentro de los sistemas que ya operan, para tareas concretas: leer documentos, clasificar lo que llega, responder preguntas sobre sus propios datos, preparar textos que después revisará una persona. Construido con evaluación y control de costes, porque una función que nadie puede medir es una función en la que nadie puede confiar.
La decisión
Cuándo es la elección correcta.
La mayoría de las funciones de IA fallan de las dos mismas formas. Se colocan donde se ven en lugar de donde ahorran tiempo, y se entregan sin ninguna manera de saber si su salida es correcta. Un resumen equivocado una vez de cada veinte es peor que ningún resumen, porque el vigésimo caso es el que llega al cliente.
El segundo fallo son el coste y la latencia descubiertos en producción. Un prompt que va bien en pruebas se vuelve caro a diez mil llamadas al día, y una función de nueve segundos no se usará por buena que sea. Son dos restricciones de diseño, ambas baratas de abordar pronto y penosas de corregir después.
Partimos de la tarea en lugar de la tecnología: qué se hace a mano, con qué frecuencia y qué cuesta cuando sale mal. Después construimos un conjunto de evaluación antes que la función, para que la pregunta de si funciona tenga respuesta. A menudo resulta que no hace falta ningún modelo, y lo decimos.
Lo que se obtiene
Qué cubre el encargo.
Extracción documental
Facturas, pedidos, extractos y formularios leídos en campos estructurados, con un indicador de confianza visible para que los casos dudosos vayan a una persona en vez de pasar en silencio.
Clasificación y enrutamiento
Peticiones entrantes, tickets y documentos dirigidos a la cola correcta, con reglas auditables en vez de opacas.
Búsqueda sobre sus propios datos
Una búsqueda sobre sus documentos y registros que cita sus fuentes, para que una respuesta pueda comprobarse en vez de creerse.
Redacción sujeta a revisión humana
Respuestas, resúmenes y descripciones preparados para que una persona los revise. Esa revisión es una decisión de diseño, no una advertencia.
Evaluación previa a la puesta en marcha
Un conjunto anotado y una tasa de acierto medida, para que cambiar de prompt o de modelo sea una comparación en lugar de una intuición.
Control del coste y la latencia
Caché, enrutamiento de modelos según dificultad y alertas de presupuesto, porque una tarifa por llamada se convierte en una factura mensual que nadie había calculado.
Stack
Con qué lo construimos.
Elegidos proyecto a proyecto. Aquí no se impone nada por defecto, y el equipo que se encargará del mantenimiento pesa tanto como el problema.
Modelos
Claude, GPT o un modelo de pesos abiertos, elegido tarea a tarea por calidad y coste medidos y no por marca.
Búsqueda documental
PostgreSQL con pgvector donde basta, un almacén vectorial dedicado donde el volumen lo justifica.
Orquestación
Código sencillo y legible preferentemente. Frameworks de agentes pesados solo cuando compensan su coste de depuración.
Evaluación
Conjuntos de pruebas versionados ejecutados en el pipeline, para que una regresión la detecte la integración continua y no un cliente.
Privacidad
Ubicación de los datos, plazo de conservación y depuración decididos antes de la primera llamada, incluida la cuestión de si una consulta puede salir de su infraestructura.
Comparación
IA superpuesta frente a IA que se gana su sitio.
La mayoría de las funciones de IA fallan de las dos mismas formas: se colocan donde se ven en lugar de donde ahorran tiempo, y se entregan sin ninguna manera de saber si su salida es correcta.
| Aspecto | IA añadida por encima | Cómo lo construimos |
|---|---|---|
| Adónde conduce | Donde luce bien: un recuadro de chat en el panel de control | Donde está realmente el trabajo manual, que rara vez es lo más vistoso |
| Saber que funciona | Alguien lo probó unas cuantas veces y parecía correcto | Un conjunto anotado a partir de sus casos reales, con una tasa de acierto medida antes de la puesta en marcha |
| Cuando no es seguro | Responde igualmente, con la misma seguridad que cuando acierta | Todo lo que quede por debajo de su umbral va a una persona, y ese umbral lo fija usted |
| Coste | Descubierto en la factura del primer mes | Estimado durante el alcance, con caché, enrutamiento de modelos y alerta de presupuesto |
| Latencia | Descubierta en producción, tras lo cual la función deja de usarse en silencio | Una restricción de diseño con una cifra, porque una función de nueve segundos no se usará |
| Cambiar el prompt o el modelo | Un cambio que nadie puede evaluar, así que nadie se atreve a hacerlo | Una comparación medida sobre el mismo conjunto de pruebas, ejecutada en integración continua |
Cómo se desarrolla
De la primera conversación a estar en producción.
Orientativo para un trabajo de esta naturaleza. El piloto no es opcional: nada se conmuta hasta que los usuarios dicen que aguanta.
- 1 semana
Identificar el trabajo
Qué se hace a mano, con qué frecuencia y qué cuesta cuando sale mal. A veces la respuesta es una regla o un formulario mejor, y lo decimos.
- 1 semana
Construir el conjunto de evaluación
Casos reales, anotados, antes de que la función exista. Sin eso no hay forma de distinguir una mejora de una regresión.
- 3 a 5 semanas
Construir y medir
La integración, la revisión humana, la caché y el control de costes, medidos sobre el mismo conjunto en cada cambio.
- 2 a 3 semanas
Piloto y ajuste
En marcha sobre una parte del volumen real, con la revisión ajustada de forma conservadora y relajada solo en la medida en que las cifras medidas lo justifiquen.
Después de la puesta en marcha
Qué cambia.
- El paso manual que la función debía eliminar desaparece de verdad, en lugar de quedar solo asistido.
- Los casos inseguros llegan a una persona en lugar de pasar en silencio, y eso es precisamente lo que hace seguro dejarla funcionando.
- Cambiar de prompt o de modelo pasa a ser una comparación en vez de una apuesta.
- La factura mensual es una cifra que alguien previó, no una sorpresa.
Descrito cualitativamente a propósito. No publicamos porcentajes de mejora que no podamos vincular a un cliente concreto con su consentimiento.
Preguntas
Preguntas frecuentes.
¿Se usarán nuestros datos para entrenar el modelo de un tercero?
No con las configuraciones que desplegamos. Las condiciones de las API empresariales excluyen el entrenamiento con los datos enviados, y donde eso no convence ejecutamos un modelo de pesos abiertos en su propia infraestructura. Se decide antes de integrar nada.
¿Cómo sabéis que la IA acierta?
Construimos un conjunto de evaluación anotado a partir de sus casos reales antes de entregar la función, y medimos sobre él. Todo lo que quede por debajo del umbral acordado va a una persona en lugar de continuar, y ese umbral lo fija usted.
¿Cuánto cuesta mantenerlo en marcha?
Depende del volumen y del modelo elegido, y lo estimamos durante el alcance en lugar de después de la puesta en marcha. La caché, el envío de los casos sencillos a modelos más baratos y una alerta mensual de presupuesto forman parte del proyecto.
¿Realmente necesitamos IA?
A menudo no. Una regla bien colocada, un formulario mejor o un informe fijo resuelven una parte sorprendente de lo que se plantea como un problema de IA, por una fracción del coste y sin ninguna incertidumbre. Cuando es así, se lo diremos.
¿Podéis ejecutar un modelo en nuestra propia infraestructura?
Sí, con un modelo de pesos abiertos donde la ubicación de los datos o las cláusulas contractuales lo exijan. El equilibrio está entre calidad y carga operativa frente a control, y merece resolverse con resultados medidos para su tarea real y no por principio.
¿Y si la IA se equivoca delante de un cliente?
Es exactamente lo que la revisión humana y el umbral de confianza sirven para evitar, y ambas son decisiones de diseño tomadas antes de entregar, no una advertencia añadida después. Donde equivocarse sale caro, el ajuste correcto es preparar para revisión y no actuar nunca sin supervisión.