Ingeniería de IA
Gemini Enterprise integra paneles de revisión mediante MCP Apps
Una herramienta puede abrir un panel dentro del chat. Qué cambia al corregir datos, cómo se comunica el resultado al asistente y dónde validar una confirmación.
Corregir datos dentro de la conversación
Gemini Enterprise puede mostrar una interfaz interactiva asociada a una herramienta MCP dentro del chat. La guía de Google del 19 de octubre explica cómo integrar ese espacio de trabajo con un servicio propio. Para revisar varios campos, un panel permite verlos juntos, corregirlos y decidir cuándo confirmar el resultado, sin convertir cada ajuste en otro mensaje al asistente.
La extensión MCP Apps está marcada como estable desde el 26 de enero de 2026. La guía de octubre desarrolla su integración en Gemini Enterprise; no es el estreno del formato. Hace falta un host que lo soporte. Conectar un servidor MCP a cualquier cliente no garantiza que también pueda mostrar su interfaz.
El host conecta la herramienta con el panel
La herramienta declara un recurso HTML con una URI ui://. Cuando se invoca, el host recupera esa interfaz y la muestra en un iframe aislado. Los mensajes entre panel y host permiten recibir resultados y solicitar otras herramientas a través del propio host. Así la interfaz puede ofrecer controles preparados para la tarea.
El borrador visible y lo que conoce el asistente necesitan una coordinación explícita. La extensión contempla ui/update-model-context para comunicar contexto que se utilizará en turnos posteriores. Cambiar un campo no significa que el modelo ya lo haya leído ni que ese valor se haya guardado en el sistema de negocio.
En A2UI, el agente describe una composición que la aplicación representa con su catálogo de componentes. Aquí una herramienta referencia una interfaz HTML servida por su desarrollador. Son formas de integrar interacción con responsabilidades distintas; conviene elegir según el espacio de trabajo que necesita el producto y el host que lo va a mostrar.
Del PDF a una ficha confirmada
Una aplicación posible es revisar una ficha de producto extraída de un PDF. El asistente solicita los datos y el panel muestra referencia, cantidad y versión. En un ejemplo ficticio, la ficha S-18 tiene 12 unidades guardadas y la persona corrige el borrador a 9. Hasta confirmar, el registro debe seguir conservando las 12 unidades.
Al confirmar, el servicio necesita comprobar el permiso del usuario, la referencia y la versión de la ficha, además de validar la cantidad. Si otra persona la ha modificado mientras el panel estaba abierto, conviene devolver ese conflicto y recuperar el dato vigente. El resultado aceptado es el que después se comunica al asistente.
Para concretar estos controles preparé una simulación local en memoria, sin Gemini, OAuth ni servidor MCP. La confirmación válida guarda 9 unidades y avanza de la versión 7 a la 8. Un reintento idéntico devuelve ese resultado sin otra escritura; reutilizar su identificador con datos distintos produce un conflicto. Esto comprueba el ejemplo de guardado, no la integración de Google.

Servicio y usuario se autentican por separado
En la integración descrita para un servicio privado de Cloud Run hay dos identidades. IAM comprueba qué servicio de Gemini Enterprise puede invocarlo. La aplicación verifica además el token OAuth del usuario. Permitir la entrada al servicio no identifica por sí solo qué persona está autorizada para editar una ficha.
La documentación actual precisa que Gemini Enterprise envía el token de identidad del servicio cuando se usa la URL predeterminada .run.app; ese envío no se realiza si el servicio utiliza un dominio personalizado. También exige configurar el conector, sus políticas de organización y las acciones habilitadas. Las acciones empiezan desactivadas. Son condiciones de esa integración, no ajustes que el panel resuelva por sí solo. Por defecto, las llamadas a acciones requieren confirmación del usuario.
El iframe limita la relación de la interfaz con el host. La autorización para guardar pertenece al servicio que modifica los datos. Ocultar un botón puede ayudar a presentar el recorrido correcto, pero el backend debe mantener el control aunque reciba una petición construida fuera del panel.

Evaluar lo que queda guardado y lo que entiende el asistente
La simulación deja una lista concreta de casos para una prueba posterior con el host real. Editar o cancelar debe conservar el registro. Una cuenta sin permiso y una versión antigua deben rechazarse. La confirmación válida debe quedar registrada, y el asistente debe recibir el resultado confirmado en vez de seguir usando el borrador anterior.
Empezaría por un panel de revisión acotado, con campos conocidos y una acción final clara. Compararía errores de corrección, coherencia del estado y tiempo hasta una ficha aceptada. MCP Apps resulta útil cuando ese espacio permite trabajar mejor con los datos; una respuesta que solo necesita leerse puede seguir resolviéndose con texto.
| Caso de la simulación local | Resultado observado |
|---|---|
| Borrador sin confirmar | 0 escrituras; se conservan 12 unidades |
| Usuario sin permiso o versión antigua | Petición rechazada; 0 escrituras |
| Confirmación válida | 9 unidades, versión 8; 1 escritura |
| Reintento idéntico de la confirmación | Mismo resultado; sigue habiendo 1 escritura |