Google lanza una API para elegir acciones con una latencia de 150–250 ms

Se ha acumulado una cola de solicitudes de soporte y un LLM debe decidir a dónde enviar cada una: a facturación, al departamento técnico o a un gestor de cuentas. Para tomar una sola decisión, el equipo configura la generación de JSON, valida el formato y gestiona las respuestas fallidas. Google propone una API específica para estas tareas: el desarrollador define las opciones permitidas y el modelo devuelve sus probabilidades. Es una candidata interesante para experimentar allí donde el producto necesita elegir rápidamente la siguiente acción.

En el anuncio de Google, el nuevo servicio se llama Gemini Decisions API, y el modelo, Gemini Decision 1. Evalúa las respuestas propuestas en una sola pasada. La latencia anunciada es de 150–250 ms, pero hay un matiz importante: las mediciones corresponden a contextos de hasta 16.000 tokens. Sería un error dar por hecho que esa velocidad se mantiene con cualquier documento largo.

Cómo se traduce esto en un producto

Imaginemos un servicio que clasifica consultas de clientes. Llega un correo con una captura de pantalla de un cargo. El desarrollador define tres categorías: consulta sobre facturación, problema técnico y otros. Además, puede preguntar si la consulta requiere una respuesta urgente. Estas comprobaciones se refieren al mismo material, por lo que resulta práctico agruparlas en una sola petición.

A partir de ahí entra en juego la lógica habitual del producto. Si la puntuación de la categoría elegida supera el umbral establecido, la solicitud pasa automáticamente a la cola correspondiente. Si la confianza es insuficiente, se deriva a un agente humano. Por ejemplo, el equipo podría empezar con un umbral del 95% y ajustarlo después según los resultados de las pruebas. Es un ejemplo hipotético de configuración, no un valor recomendado por Google.

La API admite preguntas de sí o no, selección entre opciones y puntuaciones en una escala definida. Entre los formatos de entrada figuran texto, imágenes, audio, vídeo y PDF. La utilidad práctica de la multimodalidad está clara: el correo y la captura adjunta pueden analizarse juntos, conservando los detalles relevantes para la decisión.

Aun así, el desarrollador tendrá que describir las opciones con suficiente claridad. Si dos categorías se solapan, las probabilidades por sí solas no corregirán la clasificación. Primero hay que acordar en qué se diferencia una consulta sobre un reembolso de una reclamación por un cargo, y solo después automatizar la distribución.

Qué comprobar detrás de las promesas de velocidad y precio

Google indica un precio de $0,10 por millón de tokens de entrada y ningún cargo por los de salida. El material compartido se factura una sola vez por petición, mientras que las preguntas añaden sus propias instrucciones y criterios. El servicio permite plantear hasta 1000 preguntas sobre una misma entrada; el contexto máximo es de 256.000 tokens.

Para un equipo, esto invita a calcular el coste de su operación concreta. ¿Cuántos tokens ocupan las instrucciones? ¿Cuántas preguntas hacen falta realmente? ¿Con qué frecuencia tendrá que revisar el resultado una persona? Una llamada barata puede aportar un ahorro modesto si después sigue habiendo una gran cola de trabajo manual.

La afirmación de que el coste se reduce a una quinta parte también requiere contexto. En la fuente original, Google compara el servicio con Gemini 3.5 Flash-Lite utilizando un mismo conjunto de pruebas. No es una promesa de dividir entre cinco los gastos de cualquier aplicación. Para hacer un cálculo propio se necesitan el modelo actual, documentos reales y los mismos requisitos de calidad.

Hay que comprobar las probabilidades con datos propios

Lo más interesante de esta interfaz es la posibilidad de controlar la automatización mediante un umbral. Pero un 95% en la respuesta todavía debe contrastarse con la proporción real de decisiones correctas en tus consultas. Resulta especialmente útil evaluar por separado las categorías poco frecuentes y los casos ambiguos: suelen ser los que provocan errores costosos.

Yo empezaría por una operación acotada, como distribuir solicitudes entre departamentos. Reuniría una muestra etiquetada, compararía la API con la solución actual y observaría tres indicadores: los errores de enrutamiento, el tiempo de respuesta y la proporción de consultas que siguen en manos de un agente humano. Después elegiría el umbral operativo.

Para quien gestiona el producto, el resultado de esa prueba es mucho más útil que una tabla general de benchmarks. Mostrará cuántas solicitudes se pueden procesar automáticamente manteniendo los errores dentro de un límite aceptable. Y dará al desarrollador una base concreta para decidir si merece la pena incorporar el nuevo servicio al sistema en producción.