La materia prima de la base: 2.875 códigos, 1.897 consultas DGT y 8.583 filas de obligaciones
No basta con tener los códigos del IAE y del CNAE: hay que cruzarlos, enriquecerlos con consultas vinculantes de la DGT y precomputar las obligaciones para que un agente de IA no alucine. Así const...
Este ensayo se publico primero en brianmenagomez.com/blog/materia-prima-base-2875-codigos-1897-consultas-dgt-8583-obligaciones.
La materia prima de la base: 2.875 códigos, 1.897 consultas DGT y 8.583 filas de obligaciones
Cuando arranqué Conversor no tenía claro qué forma iba a tomar la base de datos. Sabía que necesitaba cruzar el IAE con el CNAE —las dos clasificaciones oficiales de actividades en España— pero imaginé que con un par de tablas y un fichero de correspondencias de la Agencia Tributaria bastaba. Me equivoqué de pleno.
El problema real no era tener los códigos. Era mantenerlos vivos. El IAE tiene más de mil epígrafes. El CNAE ha tenido tres revisiones desde 2009. La Dirección General de Tributos publica consultas vinculantes cada semana y muchas reinterpretan qué epígrafe le toca a una actividad concreta. Si lo dejas congelado, en seis meses está obsoleto. Si lo mantienes a mano, te vuelves loco.
El primer intento: una tabla plana y un fichero de la AEAT
Mi primera versión fue ingenua. Bajé la tabla de correspondencias que publica la Agencia Tributaria, la metí en una base de datos y monté un punto final que devolvía el CNAE dado un IAE. Parecía suficiente. Unas ochocientas filas con la equivalencia oficial, cuatro columnas y listo.
Funcionó para la demo. Pero en cuanto empecé a probar casos reales —actividades que un autónomo mete en el modelo 036, consultas reales de epígrafes de empresa— el castillo se vino abajo. La tabla oficial deja huecos. Hay epígrafes del IAE sin correspondencia directa en CNAE. Hay actividades del CNAE-2025 que no existían cuando se publicó la última tabla de equivalencias. Y, sobre todo, hay matices que solo aparecen en las consultas vinculantes de la DGT: una misma actividad puede ir a un epígrafe u otro según cómo se ejerza, con local o sin él, con venta al público o solo a empresas.
El error: confundir un listado con una base de conocimiento
Lo que falló no fue la tecnología. Fue la premisa. Yo trataba el problema como una migración de datos puntual —copiar una tabla oficial, validarla, servirla— cuando en realidad era un problema de mantenimiento continuo. Cada consulta vinculante nueva es un dato que afina la clasificación. Cada revisión del CNAE parte el mapeo anterior en pedazos. Cada cliente que pregunta "¿y esto en qué epígrafe va?" está generando una arista nueva en el grafo.
Si la base no recoge ese conocimiento, no sirve. Y mantenerla a mano era insostenible: entre las consultas de la DGT, los cambios normativos y las peticiones de los usuarios, habría necesitado un equipo de personas dedicadas solo a actualizar correspondencias. Yo soy una persona, no un equipo.
La solución: tres capas, precomputadas y cruzadas
La base que tengo hoy tiene tres capas, no una. Cruzo las tres y guardo el resultado precomputado para que cada petición sea instantánea.
La primera capa son los códigos: 2.875 en total. De ellos, 1.186 son epígrafes del IAE, 1.060 son códigos del CNAE vigente y 629 pertenecen al CNAE-2009, que mantengo porque hay sistemas antiguos —y entidades públicas— que aún lo usan. La correspondencia entre ellos es bidireccional: te doy el CNAE de un IAE, pero también los posibles IAE de un CNAE. Eso no lo da la tabla oficial de la AEAT.
La segunda capa son las consultas de la DGT: aproximadamente 1.897 consultas vinculantes cruzadas con los códigos IAE. Cada consulta es una resolución de la Dirección General de Tributos que dice, para un caso concreto, qué epígrafe aplica. Cruzándolas con los códigos, sé qué epígrafes han generado más dudas, cuáles han tenido cambios de criterio y qué actividades están en zonas grises. Eso no lo tiene ningún listado oficial: hay que leer las consultas, extraer la conclusión y vincularla al código. Lo hice.
La tercera capa son las obligaciones fiscales: 8.583 filas de IAE por modelo. Aquí guardo, para cada epígrafe, qué modelos tributarios está obligado a presentar —IVA, IRPF, retenciones, intracomunitarias— según su clasificación. No las calculo al vuelo en cada petición. Las tengo precomputadas. Cuando un agente de IA pregunta "¿qué obligaciones tiene un 653.2?", la base devuelve las filas en milisegundos sin hacer una sola operación. Es la diferencia entre que el agente obtenga la respuesta o alucine.
El resultado es un dato enriquecido, cruzado, listo para agentes y mantenido. No es un raspador de la AEAT que haya que vigilar cada semana por si cambia el formato de la página. Es una base de conocimiento que se actualiza con criterio editorial: yo decido qué entra, yo verifico la fuente y yo mantengo la integridad de las correspondencias.
Qué aprendí
La lección no es técnica. Es de producto. Un dato público no es un producto. El producto es el mantenimiento de ese dato: la actualización, el cruce, la precomputación de lo que el usuario va a necesitar y el formato en el que lo va a consumir. La AEAT publica los códigos. La DGT publica las consultas. Pero cruzarlos, mantenerlos y servirlos listos para un agente de IA —ese es el trabajo que nadie más está haciendo.
Y es un trabajo que se acumula. Cada mes que pasa, la base vale más que el mes anterior, porque tiene más consultas cruzadas, más correspondencias afinadas y más obligaciones verificadas. No es un activo que se deprecie. Es uno que crece.
—
Todos los datos de la base —los 2.875 códigos, las consultas de la DGT y las obligaciones precomputadas— están disponibles en abierto: