• El valor de la IA en las administraciones tributarias depende del problema que resuelve y de si ofrece mejores resultados que el proceso vigente, con costos y riesgos aceptables.
• Los pilotos permiten comprobarlo en un entorno controlado, comparando desempeño, costos y riesgos y verificando si las salvaguardas funcionan en la práctica.
• Un piloto exitoso proporciona evidencia para decidir si corresponde descartar, ajustar, ampliar o preparar el escalamiento de una solución.
Las administraciones tributarias llevan años utilizando analítica avanzada, aprendizaje automático e inteligencia artificial para detectar riesgos, seleccionar casos, atender consultas y automatizar tareas.
En 2023, el 69% de las administraciones analizadas por la OCDE había implementado y utilizaba IA, incluido el aprendizaje automático, mientras que otro 24,1% se encontraba en proceso de implementación. En América Latina y el Caribe, los datos del Centro Interamericano de Administraciones Tributarias (CIAT), muestran una diferencia importante entre tecnología: en 2022, entre 34 administraciones tributarias, el 70,6% utiliza o estaba implementando herramientas de ciencias de datos y analítica, mientras que IA se encontraba en uso o en implementación en 23,5%. Estos indicadores abarcan distintas aplicaciones de IA y no reflejan específicamente el uso de inteligencia artificial generativa.
La irrupción de la IA generativa marca un nuevo paso en esta evolución tecnológica, ampliando oportunidades para analizar documentos, generar borradores, responder consultas y facilitar el acceso al conocimiento institucional. Pero también introduce riesgos específicos, como respuestas inventadas, divulgación de información confidencial y dependencia de proveedores externos.
El piloto permite evaluar estas oportunidades y riesgos antes de integrar la solución en la operación. En un entorno acotado, compara su desempeño con el proceso vigente, identifica fallas, estima costos y prueba salvaguardas.
Su pregunta central es: ¿mejora esta tarea frente al proceso actual, con costos y riesgos aceptables? Para responderla, conviene definir seis elementos.
1. Elegir un problema, no una herramienta
El punto de partida debe ser un cuello de botella observable: expedientes demorados, consultas repetitivas o una selección de casos poco precisa. «Probar un chatbot» describe una solución, no el problema. El equipo debe acotar una tarea, identificar al usuario y medir la línea de base: tiempo, costo, calidad y errores del proceso actual.
No todo problema requiere un modelo de lenguaje. Los datos estructurados pueden resolverse mejor con reglas o modelos predictivos; los documentos, con clasificadores especializados; y el resumen o la consulta de normativa, con modelos de lenguaje conectados a fuentes institucionales. La regla es elegir la alternativa menos compleja que permita alcanzar los resultados y umbrales definidos.
Para [usuario], mejoraremos [resultado] mediante [tarea asistida], comparándola con [proceso actual] durante [periodo], sin delegar [decisión reservada a una persona].
2. Definir qué hará la IA y quién responderá
La IA puede recuperar información, preparar un borrador, formular una recomendación o ejecutar una acción. Cuanto más influya en una fiscalización, devolución o sanción, mayores deben ser las exigencias de explicación, trazabilidad y revisión humana. La supervisión solo es efectiva si la persona dispone de información, tiempo y autoridad para cuestionar o rechazar el resultado.
Estas exigencias también deben incorporarse en la arquitectura: fuentes autorizadas, permisos, límites de acción y mecanismos para corregir o interrumpir su funcionamiento. Por eso, una vez delimitadas la tarea y la responsabilidad, corresponde examinar el sistema completo, o sea, modelo, datos, herramientas, integraciones y controles, y no únicamente el modelo utilizado.
Una solución institucional combina el modelo con fuentes de conocimiento, una plataforma que gestiona accesos y registros, la aplicación y sus controles. Un agente añade autonomía al elegir pasos e invocar herramientas autorizadas; por eso, el riesgo depende también de los datos que consulta, las acciones que ejecuta y los permisos que recibe.
Para tareas delimitadas puede ser suficiente un modelo pequeño de lenguaje (SLM, por su sigla en inglés); otras pueden requerir un modelo grande (LLM, por su sigla en inglés). En aplicaciones generativas basadas en conocimiento institucional, la generación aumentada por recuperación (RAG, por su sigla en inglés) puede conectar el modelo con fuentes aprobadas sin entrenarlo desde cero. Las alternativas —comerciales, abiertas o desplegadas en infraestructura propia— deben compararse con los mismos casos y evaluarse según la calidad, las respuestas inventadas, la latencia, el costo total, la privacidad y la auditabilidad.
El Perfil de IA Generativa del NIST ofrece orientaciones para evaluar el desempeño y gestionar riesgos de la IA generativa. El objetivo es elegir la arquitectura más sencilla que cumpla con los umbrales del caso. Sin embargo, ninguna arquitectura es viable si los datos que la alimentan son inadecuados o quedan expuestos.
3. Proteger los datos antes de conectarlos
Antes de utilizar datos, deben verificarse su origen, calidad, representatividad, permisos y restricciones. Cuando sea posible, las primeras pruebas deberían emplear datos sintéticos o anonimizados, cuentas institucionales y casos independientes para evaluar el sistema.
Si interviene un proveedor, debe precisarse qué información se envía, dónde y durante cuánto tiempo se procesa y almacena, quién puede acceder y cómo se eliminará. No utilizar los datos para entrenar el modelo no significa que no se retengan. El Perfil de IA Generativa del NIST recomienda proteger los datos y gestionar los riesgos derivados de terceros. Con datos reales también deben verificarse la base jurídica, la minimización, los controles de acceso y las transferencias internacionales aplicables.
Una vez protegidos los datos, corresponde demostrar si la solución aporta valor.
4. Acordar qué significa éxito
La precisión técnica no basta. Antes de comenzar, el piloto debe establecer una línea de base, indicadores y umbrales para continuar, ajustar o detener la solución en cuatro dimensiones:
- Operación: tiempo, costo y retrabajo.
- Calidad: precisión y respuestas correctas.
- Riesgo y equidad: falsos positivos, falsos negativos e incidentes.
- Adopción: uso efectivo, correcciones y satisfacción de los usuarios.
Un caso brasileño muestra por qué. Las primeras pruebas de un proyecto de IA para apoyar la gestión de litigios tributarios utilizaron 2.000 expedientes etiquetados manualmente y alcanzaron una sensibilidad y una especificidad superiores al 80%. Es un resultado técnico prometedor, pero no demuestra por sí solo ahorro, equidad ni una mejor calidad de la decisión final.
Por eso, además de medir resultados, el piloto debe revelar cuándo funciona y cómo puede fallar.
5. Probar también cómo falla
El entorno inicial debe limitar usuarios, datos, duración y consecuencias. Cuando sea posible, conviene empezar en «modo sombra»: el sistema genera resultados, pero no interviene en casos reales mientras se compara con el proceso vigente.
Las pruebas deben incluir situaciones tanto normales como adversas. En modelos predictivos: datos incompletos, cambios en los datos y errores entre grupos. En IA generativa: afirmaciones inventadas, instrucciones maliciosas, divulgación de información, respuestas inconsistentes y fuentes incorrectas.
El equipo debe integrar las áreas usuarias, de datos, seguridad, privacidad, asuntos jurídicos y control interno. El marco del NIST para la IA organiza este trabajo en cuatro funciones: gobernar, mapear, medir y gestionar. Las pruebas deben documentar resultados, incidentes y límites observados. Esa evidencia servirá para determinar el siguiente paso.
6. Cerrar con una decisión, no con una demostración
El piloto debe concluir con evidencia que reúna la línea de base, los resultados, costos e incidentes, la experiencia de los usuarios, limitaciones y riesgos residuales. Con ella, la institución debe decidir si detiene la iniciativa, rediseña la solución, amplía el piloto de forma acotada o prepara su escalamiento.
Preparar el escalamiento no es una consecuencia automática de un buen resultado técnico. Un piloto demuestra viabilidad acotada; llevar la solución a la operación exige integrar procesos, arquitectura, talento, compras, presupuesto, gobernanza y monitoreo permanente, capacidades destacadas por la OCDE al analizar el paso de los pilotos de IA a su implementación.
Por eso, estas condiciones deben acordarse desde el comienzo. Un buen piloto no termina demostrando que la tecnología funciona, sino determinando si genera suficiente valor para justificar el siguiente paso.
La ficha que debe aprobarse
Antes de comenzar, los equipos de negocio, tecnología, datos, seguridad y cumplimiento deben acordar las preguntas que el piloto responderá. El patrocinador debe aprobar una ficha breve que sintetice los objetivos, supuestos y criterios de evaluación de la iniciativa:
| Problema | ¿Qué tarea y resultado se mejorarán frente a qué línea de base? |
| Arquitectura | ¿Por qué esta solución y qué alternativas se compararon? |
| Datos | ¿Qué información se usará, dónde se procesará y bajo qué controles? |
| Responsabilidad | ¿Qué hará la IA y qué decisión seguirá siendo humana? |
| Evidencia | ¿Qué indicadores y umbrales determinarán el éxito? |
| Riesgos | ¿Qué fallos se probarán y qué obligará a detenerse? |
| Gobernanza | ¿Quién aprueba, supervisa, documenta y responde? |
| Salida | ¿Cuándo se decidirá detener, rediseñar, ampliar o escalar? |
Un piloto debe responder si la IA es la mejor alternativa
La IA ofrece una gran oportunidad para mejorar la eficiencia y la efectividad de las administraciones tributarias. Sin embargo, su potencial no elimina una realidad fundamental: su adopción no implica necesariamente mejores resultados.
El desafío no es multiplicar las demostraciones, sino convertir los problemas institucionales en pruebas comparables y auditables sobre cuándo utilizar IA, para qué, con qué límites y en qué condiciones. Solo entonces comienza la segunda conversación: cómo pasar del piloto a una capacidad institucional sin perder el control, la legitimidad ni el propósito público.