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.
| Lo que se anuncia | Lo que de verdad cambia | Cómo se nota |
|---|---|---|
| Una página nueva | Nada, si el trámite sigue igual por dentro. | El ciudadano sigue yendo tres veces a la ventanilla. |
| Un chatbot | La primera respuesta y el horario de atención. | Baja el tiempo de espera telefónica, no el número de requisitos. |
| Digitalizar formatos | El soporte del documento, no la duplicación. | El mismo dato se sigue capturando en tres sistemas. |
| Automatizar el proceso actual | La 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 digitalizar | El 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.
La secuencia que evita el fracaso
- 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.
| Tarea | Uso legítimo | Revisión humana obligatoria |
|---|---|---|
| Clasificar reportes ciudadanos | Priorizar y enrutar al área correcta. | Revisar casos dudosos y corregir la categoría. |
| Capturar datos de documentos | Proponer campos y señalar el renglón de origen. | Validar cada dato antes de firmar el acto. |
| Detectar anomalías en compras | Priorizar auditorías con indicios. | Abrir expediente y decidir con pruebas. |
| Predecir demanda de servicios | Planear capacidad y presupuesto. | Aprobar el plan y sostener contingencia. |
| Atender preguntas frecuentes | Responder información pública y horarios. | Atender casos particulares y recursos. |
| Evaluar elegibilidad de apoyos | Verificar requisitos objetivos. | Decidir con audiencia y derecho a impugnar. |
Tres pruebas antes de creerle a una demostración de IA
- 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.
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.
| Qué se mide | Cómo se mide | Qué evita |
|---|---|---|
| Tiempo total del trámite | Días o minutos desde la solicitud hasta la resolución. | Celebrar un portal que no reduce la espera real. |
| Número de visitas y documentos | Conteo por expediente y requisitos duplicados. | Confundir digitalizar con simplificar. |
| Tasa de devoluciones | Porcentaje de expedientes devueltos y motivo. | Ocultar errores del proceso con más captura. |
| Costo por trámite | Gasto operativo dividido entre trámites concluidos. | Comprar una solución que cuesta más de lo que ahorra. |
| Satisfacción y accesibilidad | Encuesta breve y prueba con personas con discapacidad. | Diseñar sólo para quien ya usa internet. |
| Errores y sesgos del modelo | Desempeñ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:
- El modelo puede priorizar revisiones, pero la decisión administrativa la firma una persona con cargo.
- Si el modelo se entrenó con datos históricos del propio gobierno, se asume que no tiene sesgos.
- El contrato debe permitir exportar los datos y continuar el servicio con otro proveedor.
- 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.
Pista
Evita «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
- Mide el problema antes de comprar: tiempo, visitas, documentos, devoluciones y costo por trámite.
- Rediseña el proceso antes de automatizarlo; si un paso no agrega valor, se elimina, no se digitaliza.
- Define qué datos se usan, con qué base legal, quién accede y qué se hace cuando fallan.
- Separa la IA que asiste de la IA que decide: negar, sancionar o excluir exige persona, fundamento y audiencia.
- Fija la métrica y el criterio de fracaso antes del piloto; evalúa con un área distinta a la que opera.
- Contrata resultados con cláusulas de propiedad, auditoría, salida y responsabilidad, no licencias a ciegas.
- Apaga a tiempo lo que no pasó la prueba: documentar el aprendizaje también es un resultado.
Fuentes y límites de esta lección
- gob.mx, Catálogo Nacional de Trámites y Servicios: requisitos, costos y tiempos publicados por cada dependencia.
- Secretaría de Hacienda y Crédito Público: CompraNet y datos abiertos de contrataciones (objeto, monto, proveedor y criterios).
- Ley General de Protección de Datos Personales en Posesión de Sujetos Obligados y sus lineamientos: base legal, finalidad, aviso de privacidad y derechos de las personas.
- Ley General de Transparencia y Acceso a la Información Pública: publicidad de actos, datos abiertos y acceso a la información.
- Portales federales y estatales de datos abiertos: consultar la fecha de actualización antes de citar cualquier cifra.
- Sobre inteligencia artificial: México no cuenta con un régimen general consolidado; se aplican las obligaciones vigentes de datos personales, transparencia, compras y responsabilidad administrativa. Esta lección no sustituye asesoría jurídica.
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
Curso Gobierno digital: de la ventanilla al algoritmo
La ruta completa: trámites, datos, IA, compras y evaluación.
Área: Gobierno y administración pública
Los demás cursos del área para seguir profundizando.