Genkit Dart es el framework open source de Google para construir features de IA —generación de texto, salida estructurada, tool calling y flujos agénticos— usando Dart, con el mismo código en tu backend y dentro de tu app Flutter. Se anunció el 10 de marzo de 2026 y hoy sigue en preview. Esa última palabra es la que más deberías subrayar antes de meterlo en producción, y en este artículo te explicamos por qué —y cuándo sí tiene sentido adoptarlo.
Qué es Genkit Dart (y qué no es)
Genkit ya existía para TypeScript/Node, Go y Python. La novedad es el port a Dart: por primera vez puedes escribir la lógica de IA de tu producto en el mismo lenguaje que la UI de Flutter. No es un modelo, ni un SDK de un único proveedor, ni un "ChatGPT en tu app". Es una capa de orquestación: define flows (funciones tipadas que encapsulan una tarea de IA), conecta tools (funciones que el modelo puede invocar), obliga a los modelos a devolver salida estructurada y tipada, y te da observabilidad de todo lo que pasa por medio.
La propuesta de valor es concreta: un solo lenguaje de punta a punta. Si tu equipo ya es fuerte en Dart por Flutter, dejas de mantener un backend en Python solo para hablar con un LLM. La misma lógica de IA corre como servicio backend, como proxy remoto o directamente dentro de la app.
Por qué esto importa a un equipo Flutter
El patrón habitual en 2026 para meter IA en una app móvil es: Flutter en el cliente, un backend en Python (FastAPI + LangChain o similar) para orquestar el LLM, y pegamento entre ambos. Eso significa dos lenguajes, dos pipelines de CI, dos modelos mentales y una frontera de tipos que no valida nada en tiempo de compilación.
Genkit Dart ataca justo esa fricción:
- Tipado fuerte de punta a punta. Los flows usan el sistema de tipos de Dart. El contrato entre tu UI y tu lógica de IA deja de ser un
Map<String, dynamic>y pasa a ser una clase. Menos errores tontos en el borde entre front y IA. - Neutralidad de proveedor. Soporta Google (Gemini), Anthropic (Claude) y OpenAI —además de cualquier API compatible con OpenAI— de serie. Cambiar de modelo es cuestión de cambiar el plugin, no de reescribir la integración. Para quien lea nuestro trabajo sobre FinOps de IA y control de coste de tokens, esto es oro: puedes enrutar por coste sin tocar la lógica.
- Tools y flows agénticos. El modelo puede llamar funciones que tú defines (consultar tu base de datos, pegar a una API interna) dentro de un flujo tipado y observable. Es el mismo terreno que tratamos en ingeniería de contexto para agentes en producción.
- Dev UI local. Un panel en localhost donde pruebas prompts, ves traces y depuras flows sin desplegar nada. Esto sí es un salto real de productividad respecto a "printf debugging" contra una API de LLM.
- On-device y MCP. El ecosistema de plugins ya incluye Gemini Nano vía Chrome (inferencia en el dispositivo) e integración con Model Context Protocol. La pieza de MCP conecta con lo que ya cubrimos sobre el servidor MCP en Dart.
Cómo se ve en código
Un flow con salida estructurada y una tool, en Dart, se parece a esto (simplificado):
import 'package:genkit/genkit.dart';
import 'package:genkit_google_genai/genkit_google_genai.dart';
final ai = Genkit(plugins: [googleAI()]);
// Una "tool" que el modelo puede invocar
final getStock = ai.defineTool(
name: 'getStock',
description: 'Devuelve el stock de un producto por SKU',
inputSchema: Schema.object({'sku': Schema.string()}),
(input, _) async => await inventory.lookup(input['sku']),
);
// Un "flow" tipado y observable
final answer = ai.defineFlow(
name: 'answerProductQuestion',
(String question, _) async {
final res = await ai.generate(
prompt: question,
tools: [getStock],
output: Schema.object({
'reply': Schema.string(),
'inStock': Schema.boolean(),
}),
);
return res.output; // ya validado contra el schema
},
);
Lo relevante no es la sintaxis exacta (cambiará: está en preview), sino el patrón: la salida llega validada contra un schema, la tool se ejecuta dentro del flow, y todo el flujo queda trazado en la Dev UI. Ese mismo flow puede exponerse como endpoint HTTP o ejecutarse embebido en la app.
Cuándo Genkit Dart es una buena decisión
- Tu equipo es Dart-first. Si Flutter es tu stack y no tienes un equipo de backend en Python o Go dedicado, Genkit Dart elimina un lenguaje entero de la ecuación. Ese es su caso de uso estrella.
- Prototipos y discovery de features de IA. Para validar rápido si una feature con LLM aporta valor —un asistente, un buscador semántico, un clasificador— la Dev UI y el tipado te dan velocidad sin montar infraestructura.
- Features de IA acotadas dentro de un producto Flutter existente. Un flow con tools bien definido, con salida estructurada que la UI consume directamente, encaja limpio.
- Quieres neutralidad de proveedor desde el día uno. Si prevés cambiar de Gemini a Claude o a un modelo open-weight self-hosted, la abstracción te ahorra reescrituras.
Cuándo NO lo usaríamos (todavía)
Aquí es donde toca ser honestos, porque la mayoría de tutoriales se quedan en el "hola mundo":
- Está en preview. Anunciado en marzo de 2026 y aún etiquetado como preview en el repositorio. La API puede romper entre versiones. Para un producto crítico en producción con SLA, ese riesgo no es gratis: te ata a refactors no planificados.
- Ecosistema más joven que TypeScript/Python. El Genkit de Node y Python lleva más recorrido, más plugins y más ejemplos batallados en producción. Si tu caso de uso necesita un conector concreto que solo existe allí, migrar a Dart puede costarte más de lo que ahorras.
- Cargas de trabajo de IA pesadas y desacopladas del cliente. Si tu orquestación es un sistema multiagente complejo, con colas, workers y escalado independiente, un backend dedicado —en Go sobre Cloud Run, por ejemplo— sigue siendo mejor idea que embeberlo en el ciclo de vida de una app. Lo argumentamos en orquestación multiagente en producción.
- Nunca metas claves de API en el cliente. "Ejecutar la IA dentro de la app" suena bien hasta que recuerdas que el binario es inspeccionable. Las credenciales de proveedor viven en el servidor o detrás de un proxy; el modo embebido es para inferencia on-device (Gemini Nano) o para hablar con tu backend, no para exponer tu API key de Gemini al mundo.
Genkit Dart vs. las alternativas
| Enfoque | Lenguajes | Mejor para | Coste/fricción |
|---|---|---|---|
| Genkit Dart | Solo Dart | Equipos Flutter, features de IA acotadas, prototipos | Bajo si ya eres Dart-first; riesgo de preview |
| Llamar a la API del modelo directamente | Dart (http) | Casos triviales de un solo prompt | Mínimo al inicio, se vuelve espagueti al crecer |
| Backend dedicado (Go/Python) + Genkit/LangChain | 2 lenguajes | Sistemas agénticos complejos, escalado independiente | Más infra, más maduro y probado |
No hay una respuesta universal. La pregunta correcta no es "¿es Genkit Dart lo mejor?", sino "¿dónde está la complejidad de mi producto?". Si vive en la app y la IA es una feature más, Dart de punta a punta gana. Si la complejidad vive en el backend, no fuerces la herramienta.
Nuestra recomendación
Genkit Dart es una de las piezas más interesantes que le han pasado al ecosistema Flutter en 2026: por fin puedes construir features de IA sin salir de Dart, con tipado real y una experiencia de desarrollo decente. Pero preview significa preview. Nosotros lo usaríamos hoy para discovery, prototipos y features de IA acotadas dentro de apps Flutter, monitorizando de cerca los cambios de API y sin apostar la parte crítica del negocio a una versión que aún puede romper. Para sistemas agénticos serios y desacoplados, seguimos poniendo la orquestación pesada en un backend dedicado.
En Dribba llevamos desde 2011 construyendo producto —somos Flutter Partner oficial de Google desde 2017, la única agencia española en el directorio— y más de 300 proyectos nos han enseñado que la decisión de arquitectura de IA se toma antes que la de framework. Si estás valorando meter IA en tu app Flutter y no sabes si Genkit Dart, un backend en Go o una integración directa es tu camino, hablemos: en una sesión de discovery lo aterrizamos a tu caso.
