Gobierno digital y administración pública

Gobierno digital e IA: modernizar sin vender humo

Diseñar una propuesta de gobierno digital para una administración pública: elegir un problema medible, rediseñar el proceso antes de automatizarlo, decidir en qué tareas ayuda la inteligencia artificial y en cuáles no, y cerrar con una ficha de proyecto que incluya métricas, candados de datos y cláusulas de compra.

Gobierno digital e IA: modernizar sin vender humo

La promesa fácil y la pregunta difícil «Vamos a digitalizar todo con inteligencia artificial.» Suena moderno y no compromete a nada. La pregunta que sí sirve es otra: ¿qué trámite duele, cuánto tarda hoy, qué parte del proceso se puede eliminar y qué decisión no debe tomar nunca una máquina sola? Esta lección entrena esa pregunta.

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.

Cinco anuncios frecuentes y la prueba de realidad. La última fila es la única que merece llamarse transformación digital.
Lo que se anunciaLo que de verdad cambiaCómo se nota
Una página nuevaNada, si el trámite sigue igual por dentro.El ciudadano sigue yendo tres veces a la ventanilla.
Un chatbotLa primera respuesta y el horario de atención.Baja el tiempo de espera telefónica, no el número de requisitos.
Digitalizar formatosEl soporte del documento, no la duplicación.El mismo dato se sigue capturando en tres sistemas.
Automatizar el proceso actualLa velocidad de un proceso mal diseñado.Se cometen los mismos errores, más rápido y sin quién responda.
Rediseñar y luego digitalizarEl número de pasos, documentos y decisiones.Menos visitas, menos datos repetidos, expediente único y trazable.

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.

Tres capas apiladas del gobierno digital: servicios arriba, procesos al centro y datos abajo, con una señal de funcionamiento para cada capa.
Figura propia de Lumbre Política. Si sólo se cambia la capa superior, el trámite sigue siendo el mismo por dentro: la fricción cambia de lugar, no desaparece.

La secuencia que evita el fracaso

  1. Antes de comprar nada, mide el dolor: tiempo total del trámite, número de visitas, documentos pedidos, porcentaje de expedientes devueltos. Sin línea base no hay forma de demostrar que algo mejoró.

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.

Seis tareas y el límite de cada una. La columna de la derecha no es un adorno: es la diferencia entre asistencia y decisión automática.
TareaUso legítimoRevisión humana obligatoria
Clasificar reportes ciudadanosPriorizar y enrutar al área correcta.Revisar casos dudosos y corregir la categoría.
Capturar datos de documentosProponer campos y señalar el renglón de origen.Validar cada dato antes de firmar el acto.
Detectar anomalías en comprasPriorizar auditorías con indicios.Abrir expediente y decidir con pruebas.
Predecir demanda de serviciosPlanear capacidad y presupuesto.Aprobar el plan y sostener contingencia.
Atender preguntas frecuentesResponder información pública y horarios.Atender casos particulares y recursos.
Evaluar elegibilidad de apoyosVerificar requisitos objetivos.Decidir con audiencia y derecho a impugnar.

Tres pruebas antes de creerle a una demostración de IA

  1. Pide que la demostración use datos del trámite real, no un ejemplo de laboratorio. Pregunta de dónde salen esos datos, si hay base legal para usarlos y qué pasa cuando el dato falta o viene sucio.

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.

Cuatro columnas con los candados previos a un sistema de IA: datos personales, transparencia, equidad y debido proceso, seguridad y compras; cada una con lo que exige y la pregunta que se hace.
Figura propia de Lumbre Política. Los cuatro candados se documentan antes del piloto; si uno falta, el proyecto se detiene, no se «regulariza» después.
La frase que hay que prohibir en una junta de modernización «El algoritmo lo decidió.» Ninguna autoridad puede trasladar su responsabilidad a un sistema. La decisión administrativa tiene un funcionario responsable, un fundamento y un procedimiento. La IA puede preparar el expediente; no puede firmar ni sustituir el acto.

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.

Línea de tiempo de noventa días en cinco etapas: problema y línea base, rediseño, piloto, evaluación independiente y decisión de escala.
Figura propia de Lumbre Política. La ruta pone la métrica antes que la compra: si el piloto no tiene criterio de fracaso, no es una prueba.
Seis métricas que se acuerdan antes del piloto. Cambiar la métrica a mitad del proyecto es la forma más común de maquillar el resultado.
Qué se mideCómo se mideQué evita
Tiempo total del trámiteDías o minutos desde la solicitud hasta la resolución.Celebrar un portal que no reduce la espera real.
Número de visitas y documentosConteo por expediente y requisitos duplicados.Confundir digitalizar con simplificar.
Tasa de devolucionesPorcentaje de expedientes devueltos y motivo.Ocultar errores del proceso con más captura.
Costo por trámiteGasto operativo dividido entre trámites concluidos.Comprar una solución que cuesta más de lo que ahorra.
Satisfacción y accesibilidadEncuesta breve y prueba con personas con discapacidad.Diseñar sólo para quien ya usa internet.
Errores y sesgos del modeloDesempeño por grupo, revisión de casos dudosos.Publicar un promedio que esconde daños concretos.

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.

Un área pide comprar un sistema de IA para un trámite que hoy exige tres copias de documentos que el gobierno ya tiene. ¿Cuál es el primer paso profesional?

Un chatbot de atención ciudadana quiere usar el número de teléfono y el historial de trámites de cada persona para «personalizar». ¿Qué condición debe cumplirse antes?

Cuatro afirmaciones sobre un proyecto de IA en el gobierno. Una contiene un error grave:

  1. El modelo puede priorizar revisiones, pero la decisión administrativa la firma una persona con cargo.
  2. Si el modelo se entrenó con datos históricos del propio gobierno, se asume que no tiene sesgos.
  3. El contrato debe permitir exportar los datos y continuar el servicio con otro proveedor.
  4. Las métricas del piloto se acuerdan antes de empezar y se comparan contra una línea base.

Identifica la linea con error.

Comprar un modelo de inteligencia artificial es suficiente para mejorar un trámite, aunque el proceso interno siga igual.

Une cada uso de IA con su límite profesional.

Clasifica cada propuesta según si puede ir a piloto con lo que ya tiene o si exige un candado previo.

Listo para piloto
Exige candado previo

Ordena las cinco etapas de la ruta de noventa días.

☰
☰
☰
☰
☰

Antes del piloto se fija la línea ; durante el piloto se comparan las acordadas; y para escalar se exige una evaluación y un presupuesto de permanente. Sin esas cuatro piezas, la compra es una apuesta, no una política pública.

Elige un trámite o servicio público que conozcas y responde en cinco líneas: quién lo opera, cuánto tarda hoy, qué documento se pide dos veces, qué parte se podría eliminar sin ley nueva y qué tarea podría asistir una IA con revisión humana. Si no tienes el dato, escribe la pregunta y la fuente donde lo conseguirías.

PistaEvita «digitalizar todo». Nombra un paso, un área y una métrica. Un buen proyecto cabe en una frase: reducir de X a Y el tiempo del trámite Z sin aumentar el riesgo para las personas.

Tu ficha de proyecto en una página

Chequeo de la lección

Se requiere 70% de aciertos para avanzar.

Para dominar este tema

Fuentes y límites de esta lección

Las cifras de resultado de un proyecto se citan con su documento, su fecha y su ámbito; este paquete no inventa ninguna. Los instrumentos y leyes se nombran para que puedan verificarse, no para sustituir la lectura de la norma vigente ni la asesoría jurídica de cada caso.

Para seguir