Gobierno digital e IA: modernizar sin vender humo

El escenario. Caso hipotético: un municipio de tamaño medio quiere «modernizarse». La presidenta anuncia una aplicación móvil, un chatbot y un proveedor que promete «analítica predictiva con IA». En la ventanilla, el trámite de licencia de funcionamiento sigue pidiendo seis copias de documentos que la propia administración ya tiene en otro sistema; el ciudadano regresa tres veces porque cada área revisa lo mismo; el expediente en papel se pierde y el negocio abre semanas después de lo previsto.

El proveedor propone automatizar el trámite tal como está: un robot que capture los formatos y un modelo que «decida» si la licencia procede. La solución es rápida de comprar y difícil de defender: automatiza la duplicación, esconde el problema del expediente y pone una caja negra donde debería haber una revisión con fundamento. El equipo de modernización tiene noventa días para presentar una alternativa.

Esta lección es la herramienta para construir esa alternativa. No empieza por la tecnología: empieza por el problema, el proceso y el dato. La tecnología llega al final, y sólo si el rediseño la justifica.

1. Tres capas: el servicio, el proceso y el dato

El gobierno digital se entiende mejor como un edificio de tres capas. Arriba está el servicio: lo que la persona ve, toca y usa —el portal, la aplicación, la notificación, la ventanilla única—. En medio está el proceso: las reglas, las firmas, las revisiones, el expediente y la interoperabilidad entre áreas. Abajo están los datos: los padrones, los registros, la calidad de la información, su protección y su seguridad.

La mayoría de los proyectos fracasa porque cambia sólo la capa de arriba. Se compra un portal nuevo, se maquilla el formulario y se anuncia «gobierno digital», pero el proceso interno sigue pidiendo el mismo papel y los sistemas siguen sin hablarse. El ciudadano percibe la misma fricción con otra interfaz. La transformación empieza cuando se toca la capa del proceso: se eliminan requisitos que ya están en otro sistema, se unifica el expediente, se define quién revisa qué y se firma con validez jurídica.

La capa de datos es la que sostiene todo. Un proceso digital sin datos confiables produce errores más rápido. Una base de datos sin reglas de calidad, sin permisos y sin resguardo es un riesgo, no un activo. Por eso el orden importa: problema, proceso, dato y al final tecnología. Invertir el orden es la forma más cara de no resolver nada.

2. Dónde ayuda la IA y dónde no

La inteligencia artificial no es una sola cosa. En la gestión pública aparecen cuatro familias de uso que conviene separar porque tienen riesgos distintos.

Clasificar y enrutar. Un modelo puede leer miles de reportes ciudadanos —baches, fugas, luminarias, basura— y agruparlos por tema, zona y urgencia para que el área correcta los reciba primero. El riesgo es que un reporte mal clasificado se pierda; la mitigación es una bandeja de revisión y un derecho de corrección.

Extraer y capturar. Un modelo de lenguaje puede leer un documento, identificar datos y proponerlos para captura. Ahorra tecleo y reduce errores de transcripción. El riesgo es inventar un dato que no está; la mitigación es que cada campo extraído apunte al renglón del documento y que una persona valide antes de firmar.

Detectar anomalías. En compras públicas, un modelo puede señalar patrones raros: proveedores que ganan siempre lo mismo, montos que se fraccionan, plazos que se acortan. No prueba corrupción: prioriza revisiones. El riesgo es estigmatizar a un proveedor legítimo; la mitigación es que la alerta no sea una sanción y que la decisión la tome un auditor con expediente.

Predecir para planear. Un modelo puede estimar demanda de agua, riesgo de falla de equipo o volumen de solicitudes en cierta temporada. Sirve para presupuestar y para preparar capacidad. El riesgo es tratar la predicción como certeza; la mitigación es publicar el margen de error y mantener planes de contingencia.

Lo que la IA no debe hacer sola: negar un trámite, imponer una sanción, determinar la culpabilidad de una persona, decidir la elegibilidad de un apoyo social o clasificar a alguien como riesgo sin revisión humana. Esas decisiones exigen fundamento, audiencia y posibilidad de impugnación. La regla práctica: la IA propone, una persona con nombre y cargo decide.

3. Los cuatro candados antes del piloto

Un proyecto con IA en el sector público no empieza con un contrato de software: empieza con cuatro pruebas que deben quedar por escrito. Si una falta, el piloto no se enciende.

Datos personales. Toda información sobre personas identificables requiere una base legal, una finalidad determinada y el mínimo de datos necesario. En el sector público aplican la ley general de protección de datos en posesión de sujetos obligados y sus lineamientos: aviso de privacidad, medidas de seguridad, límites de conservación y derechos de acceso, rectificación, cancelación y oposición. Un modelo entrenado con datos personales sin base legal es un pasivo, no un experimento.

Transparencia y explicabilidad. La decisión administrativa debe poder explicarse en lenguaje comprensible: qué datos se usaron, qué regla se aplicó y qué revisó una persona. Los datos abiertos y los formatos de contrataciones abiertas permiten que terceros revisen lo que el gobierno publica. Un sistema que no puede explicar por qué recomendó algo no está listo para operar.

Equidad y debido proceso. Los modelos aprenden de datos históricos y pueden reproducir sesgos: zonas con menos reportes reciben menos atención, ciertos nombres reciben más revisiones. Hay que probar el desempeño por grupos, documentar los errores y garantizar revisión humana, audiencia y derecho a impugnar. La pregunta no es sólo si el modelo acierta en promedio, sino a quién perjudica cuando falla.

Seguridad y compras. El contrato debe definir quién es dueño de los datos, dónde se alojan, quién puede acceder, cómo se audita, qué pasa al terminar el servicio y cómo se exporta todo sin depender del proveedor. Comprar «una licencia de IA» sin cláusulas de salida es entregar el expediente público a un tercero.

4. La ruta de noventa días

Una propuesta creíble cabe en un trimestre. Noventa días no alcanzan para transformar una institución, pero sí para demostrar si una idea funciona o no, con evidencia y sin comprometer el erario.

Días 1 a 15: problema y línea base. Se elige un solo trámite o servicio, se mide el tiempo total, el número de visitas y documentos, y se escucha a quienes lo padecen: ciudadanos y personal de ventanilla. El producto es una ficha de una página con la línea base y el objetivo medible.

Días 16 a 30: rediseño del proceso. Se dibuja el flujo real, se eliminan pasos y requisitos duplicados, se define el expediente único y el dueño del proceso. Aquí todavía no se compra tecnología: se acuerda qué debe pasar.

Días 31 a 60: piloto. Se implementa la solución mínima —puede ser un formulario inteligente, una bandeja de clasificación o una extracción asistida— con un grupo acotado. Se comparan las métricas contra la línea base y se documentan los fallos. Un piloto que no puede fracasar no está midiendo nada.

Días 61 a 75: evaluación independiente. Un área distinta a la que opera revisa los resultados: ¿bajó el tiempo?, ¿bajaron las devoluciones?, ¿hubo sesgos?, ¿se protegió el dato?, ¿el personal pudo operar el sistema? La evaluación se publica en versión resumida.

Días 76 a 90: decisión de escala. Si el piloto pasó, se presupuesta la operación permanente y se contrata con cláusulas de auditoría y salida. Si no pasó, se apaga y se documenta el aprendizaje. Apagar a tiempo también es gestión pública responsable.

5. Comprar resultados, no licencias

El mercado de la tecnología vende productos; el gobierno necesita resultados. La diferencia se resuelve en el contrato. En lugar de especificar «un modelo de lenguaje con tantos parámetros», se especifica qué tarea debe resolverse, con qué calidad, con qué revisión humana y con qué métrica se pagará.

Un contrato defendible incluye cinco cláusulas mínimas. Propiedad y acceso a los datos: el gobierno conserva la titularidad y el proveedor sólo los usa para el servicio. Ubicación y seguridad: dónde se alojan, quién accede y cómo se respalda. Auditoría: derecho a revisar el modelo, los registros y los resultados. Salida: exportación completa en formato abierto y continuidad del servicio si se cambia de proveedor. Responsabilidad: qué pasa si el sistema falla, daña a una persona o filtra datos.

También importa cómo se paga. Un esquema de pago atado a resultados —tiempo reducido, tasa de error, disponibilidad— alinea incentivos. Pagar todo al inicio por una licencia anual deja al gobierno sin palanca cuando el sistema no funciona. Y antes de firmar conviene preguntar por el costo total de operación: servidores, soporte, capacitación, actualizaciones y personal que revisará las salidas del sistema.

La transparencia también alcanza a la compra. Publicar el objeto, el monto, el proveedor, los criterios y los resultados permite que la sociedad revise. Los estándares de contrataciones abiertas existen precisamente para que esa información sea comparable y reutilizable, no un PDF escaneado.