Google enseña a Gemini el procedimiento público: dónde un borrador se vuelve decisión

Una ley no es un prompt. Tiene definiciones en un artículo que cambian el sentido de una palabra en otro, excepciones que se imponen a la regla general, fechas de entrada en vigor y guías de la agencia que la interpretan de forma distinta al texto literal. El trabajo público consiste en aplicar todo eso, caso por caso, y dejar un registro que explique por qué.

Ese es el problema que Google se propuso empaquetar el 20 de octubre con Gemini for government services, anunciado por el CEO de Google Cloud, Thomas Kurian, y disponible en vista previa.

Cómo lo estructuró Google

La oferta tiene cinco partes:

• Skills para el trabajo público: instrucciones y contexto reutilizables escritos por expertos de cada dominio, que aplican las leyes, los reglamentos y las guías de las agencias que rigen una tarea.
• Conectores a los sistemas de las agencias: gestión de casos, ERP, RR. HH., herramientas de colaboración y fuentes de datos federales como el Federal Register, regulations.gov y el eCFR, consultadas en su sitio sin migrar datos.
• Agentes socios de proveedores de software del sector público, como los agentes de descubrimiento y redacción de FOIA de SZNS Solutions (FOIA es el equivalente estadounidense de la Ley 19/2013 de transparencia, acceso a la información pública y buen gobierno en España).
• Un plano de control gobernado que aplica políticas a todos los agentes, con VPC Service Controls, claves de cifrado gestionadas por el cliente y Assured Workloads, incluido un límite de datos FedRAMP High.
• Salidas fundamentadas con citas a los documentos de origen.

El acceso sigue los permisos por rol y por registro que las agencias ya tienen. Google afirma que los datos y las salidas de las agencias no se usan para entrenar sus modelos fundacionales sin permiso. El estado de Missouri y el Departamento de Salud y Servicios Humanos de EE. UU. figuran como colaboradores de Google para validar las capacidades.

Borrador, propuesta o decisión

La forma más útil de leer el anuncio es ordenar sus flujos de trabajo de ejemplo según lo que la salida del agente es en realidad. Las propias descripciones de Google ya trazan la línea en la mayoría de los casos.

Borradores de investigación. La investigación normativa y regulatoria devuelve respuestas del CFR, el Federal Register, los códigos administrativos estatales y los manuales internos, con citas de página y párrafo, incluido qué norma prevalece cuando aplican a la vez normas federales y estatales. Esa última parte es interpretación jurídica. Una cita permite a quien revisa comprobar la fuente; no hace que la conclusión sea correcta. La salida es un borrador para un analista o para el equipo jurídico.

Propuestas que necesitan confirmación. El descubrimiento de FOIA reúne los registros pertinentes en un conjunto de revisión para el responsable de registros y el equipo jurídico. La redacción propone redacciones etiquetadas con la excepción legal aplicable, y exporta copias redactadas y un registro de excepciones solo después de que una persona revisora lo confirme. Aquí el agente prepara y una persona es quien confirma, que es el diseño correcto. El riesgo es el volumen: cuando un agente propone cientos de redacciones, la confirmación puede quedar reducida a un clic. Ya lo argumentamos: un human in the loop solo es un control si la persona puede cuestionar a la IA; agrupar los hallazgos para revisarlos por tandas, como describe Google, ayuda, pero la capacidad de revisión hay que planificarla.

Insumos de decisiones. La evaluación de ofertas de proveedores contrasta las ofertas con los requisitos del RFP, el FAR y las rúbricas, y da a los responsables de contratación «una base documentada para cada decisión de adjudicación». Las auditorías de subvenciones señalan costos no elegibles frente al 2 CFR 200 con citas por línea de partida. Estas salidas alimentan decisiones que conllevan responsabilidad legal. La persona responsable decide; el análisis del agente pasa a formar parte del expediente y debe conservarse como tal.

Decisiones que el agente no debería tomar. Google no afirma que el sistema tome decisiones finales de elegibilidad, aplicación o adjudicación, y las empresas que construyan sobre él tampoco deberían hacerlo. Ese límite pertenece al diseño, escrito flujo de trabajo por flujo de trabajo, no a un descargo de responsabilidad.

Qué dejar resuelto antes de un piloto

Quién es dueño de cada skill. Una skill que codifica cómo se aplica una ley es un procedimiento. Cuando el reglamento cambia, alguien debe actualizarla, probarla y dejar registrada la versión vigente para cada caso. Trate las skills como documentos de orientación controlados, con un responsable, una fecha de entrada en vigor y un ciclo de revisión.

Qué versión respondió. Si un ciudadano o un auditor impugna una decisión meses después, la agencia necesita saber qué versión de la skill, qué fuentes y qué modelo produjeron el análisis que la sustenta.

Dónde reside la autorización. Los conectores que consultan los sistemas en su sitio, con los permisos existentes, mantienen la autoridad donde ya está, en el sistema de registro. Esa es la parte más sólida del diseño, y la razón por la que la arquitectura puede funcionar: el agente razona, el sistema dueño de la transacción es quien autoriza.

Los equipos del sector privado en industrias reguladas deberían seguir de cerca esta vista previa. Cambie «ley» por «SOP» o «política de crédito» y la arquitectura es la misma, y las preguntas también.