Casi todas las firmas de auditoría han tenido ya la misma conversación: «la IA generativa nos ahorraría cientos de horas, pero no podemos subir a la nube el libro diario de un cliente». Ejecutar modelos de lenguaje en infraestructura propia, sin enviar datos a terceros, resuelve ese obstáculo. Lo que no resuelve es la responsabilidad del auditor sobre la evidencia que obtiene. Repasamos qué es exactamente una IA local, dónde aporta valor en un encargo, qué riesgos introduce y qué controles conviene exigir antes de incorporarla a la metodología.

El problema de partida: la confidencialidad no es negociable

El auditor de cuentas trabaja con la información más sensible de su cliente: libros diarios completos, nóminas, contratos, actas del consejo, correspondencia con abogados. Sobre todo ello pesa el deber de secreto que impone la Ley 22/2015, de Auditoría de Cuentas, además del RGPD cuando hay datos personales y de las cláusulas de confidencialidad de la carta de encargo.

Los asistentes de IA generativa más conocidos funcionan como servicios en la nube: el documento sale de la firma, se procesa en servidores de un tercero y, según el contrato, puede quedar registrado. Para muchos despachos esto se traduce en una política de «no usar IA con datos de clientes», que en la práctica deja la herramienta fuera del trabajo de campo.

La IA local invierte la lógica: el modelo se instala en un equipo o servidor de la firma y la información no abandona ese perímetro. El debate pasa de «¿podemos enviar estos datos?» a «¿cómo garantizamos que el resultado es fiable y está documentado?», que es la pregunta que de verdad importa en auditoría.

Qué es exactamente una IA local

Una IA local es un modelo de lenguaje cuyos parámetros (los «pesos») se descargan y se ejecutan en hardware controlado por la firma, sin llamadas a servicios externos. Es posible porque varios desarrolladores publican modelos de pesos abiertos bajo licencias que permiten su uso profesional, como las familias Llama, Mistral, Qwen, Gemma o gpt-oss. Conviene revisar la licencia concreta de cada modelo antes de usarlo en un servicio a clientes.

Un despliegue típico tiene cuatro piezas:

Pieza

Qué hace

Por qué le importa al auditor

Modelo

Genera texto, clasifica, resume, extrae datos

Su versión exacta debe quedar identificada, porque otra versión puede responder distinto

Motor de inferencia (llama.cpp, Ollama, vLLM)

Ejecuta el modelo en el hardware

Fija parámetros como la temperatura, que influyen en la variabilidad de las respuestas

Recuperación de documentos (RAG)

Busca en los documentos del encargo los fragmentos relevantes y se los pasa al modelo

Permite que cada respuesta cite su fuente, lo que hace la salida verificable

Herramientas de cálculo

El modelo delega cálculos y consultas a código o a una base de datos

Los importes los calcula un programa, no el modelo, y el cálculo es reproducible

Tamaño y hardware. La memoria necesaria depende del número de parámetros y de la precisión con que se almacenan. Con cuantización a 4 bits, cada parámetro ocupa aproximadamente medio byte: un modelo de 8.000 millones de parámetros cabe en un portátil moderno, mientras que uno de 70.000 millones necesita en torno a 40 GB de memoria de vídeo o unificada, más el espacio que ocupe el contexto. Para una firma mediana, un equipo dedicado con una o dos GPU de gama profesional, o un equipo de memoria unificada de gran capacidad, es suficiente para modelos de tamaño medio.

Lo que no hay que esperar. Los mejores modelos locales son muy competentes en lectura, extracción y clasificación de texto, pero en razonamiento complejo suelen quedar por detrás de los modelos comerciales más avanzados. El diseño del proceso debe asumir esa limitación: tareas acotadas, con fuentes y con revisión.

Dónde aporta valor en un encargo de auditoría

El mayor rendimiento está en las tareas que hoy consumen horas de lectura y clasificación de información no estructurada. La tabla recorre las fases del encargo y la norma técnica con la que se relaciona cada uso.

Fase

Uso de la IA local

NIA-ES de referencia

Qué debe verificar el auditor

Conocimiento de la entidad

Resumen de actas, memorias anteriores, informes de gestión y prensa interna; identificación de hechos relevantes del ejercicio

315 (Revisada)

Que los hechos señalados constan en el documento citado y que no se omiten asuntos relevantes

Valoración de riesgos y fraude

Clasificación de las descripciones de asientos del libro diario; señalamiento de conceptos atípicos o ambiguos para su selección

240 (Revisada), 330

Que los criterios de selección los define el equipo y que la IA solo prioriza, no decide

Contratos y compromisos

Extracción de cláusulas de financiación (covenants, garantías, vencimientos anticipados), arrendamientos y compromisos de compra

500, 505, 570 (Revisada)

Cotejo de cada cláusula extraída con el contrato original

Partes vinculadas

Cruce de nombres de terceros en contratos, facturas y actas con la relación de partes vinculadas facilitada por la dirección

550

Que las coincidencias y las ausencias se investigan; la IA no prueba que no existan otras

Procedimientos analíticos

Redacción de explicaciones a variaciones a partir de las respuestas de la dirección y la documentación soporte

520

Que la explicación está corroborada con evidencia y no es solo plausible

Litigios y hechos posteriores

Lectura de cartas de abogados, actas posteriores al cierre y correspondencia con organismos

501, 560

Que cada asunto identificado se evalúa para provisión o desglose

Cierre e informe

Comprobación de coherencia entre estados financieros, memoria e informe de gestión; revisión de la otra información

720 (Revisada), 700 (Revisada)

Que las diferencias señaladas se resuelven y las cifras se comprueban con el balance de sumas y saldos

Documentación

Borradores de memorándums y papeles de trabajo a partir de las notas del equipo

230

Que el contenido final lo revisa y firma quien tiene la responsabilidad

Dos ideas recorren todos los casos. Primero, la IA trabaja sobre el 100 % del texto disponible, algo que el muestreo tradicional no permite en documentación no estructurada, pero su cobertura no equivale a evidencia: lo que señala debe verificarse y lo que no señala no está demostrado que no exista. Segundo, los importes y cálculos deben venir de los sistemas y de herramientas deterministas, nunca de la respuesta del modelo.

Limitaciones y riesgos que el auditor debe conocer

Que los datos no salgan de la firma resuelve la confidencialidad, pero no la fiabilidad. Un modelo local tiene las mismas debilidades que uno en la nube, y a menudo más acusadas por su menor tamaño.

•         Alucinaciones. El modelo puede afirmar con seguridad algo que no figura en el documento: una cláusula inexistente, una fecha equivocada, un importe inventado. El control eficaz es exigir que cada afirmación cite el documento y la página de origen, y verificar por muestreo esas citas.

•         Variabilidad. La misma pregunta sobre el mismo documento puede producir respuestas distintas. Fijar la temperatura a cero reduce la variabilidad, pero no garantiza resultados idénticos entre ejecuciones ni entre versiones. Para la documentación, lo relevante es conservar la entrada, la configuración y la salida concreta que se usó.

•         Cálculo. Los modelos de lenguaje predicen texto; no operan con números de forma fiable. Sumar, conciliar o recalcular debe hacerse con código, hojas de cálculo o la herramienta de análisis de datos de la firma.

•         Sesgos y omisiones. El modelo tiende a resumir lo que aparece con más frecuencia o de forma más explícita, y puede pasar por alto lo inusual, que es precisamente lo que más interesa al auditor. También puede rendir peor con documentos en catalán, euskera, gallego o con terminología sectorial.

•         Calidad de las fuentes. Con recuperación de documentos, la respuesta es tan buena como lo que se le entrega. Un borrador desactualizado mezclado con la versión firmada de un contrato puede producir conclusiones erróneas.

•         Sesgo de automatización. El riesgo más serio no es técnico sino humano: aceptar la salida de la herramienta sin el escepticismo profesional exigido. El IAASB lo trata expresamente en su propuesta de revisión de la NIA 500 de agosto de 2026.

Ninguno de estos riesgos impide usar la herramienta. Todos obligan a diseñar el procedimiento para que el auditor pueda verificar lo que la IA produce.

Qué dicen las normas (y qué no)

No existe una norma de auditoría específica sobre IA, pero el marco vigente y el que está en preparación ya dicen bastante sobre cómo usarla.

Marco

Qué implica para el uso de IA local

NIGC 1-ES (gestión de la calidad de la firma)

Los recursos tecnológicos forman parte del sistema de gestión de la calidad. La firma debe decidir qué herramientas aprueba, para qué usos y cómo comprueba que funcionan como se espera

NIA-ES 220 (Revisada)

El socio del encargo responde de que los recursos, incluidos los tecnológicos, son adecuados y se usan correctamente en el encargo

NIA-ES 500 y propuesta del IAASB de 2026

La información solo se convierte en evidencia cuando se le aplican procedimientos que evalúan su relevancia y fiabilidad. La propuesta de agosto de 2026 (NIA 500, 330 y 520, en consulta hasta el 15 de diciembre de 2026) habla de «herramientas tecnológicas», cita la IA como ejemplo y aborda expresamente el sesgo de automatización

NIA-ES 230

Los papeles deben permitir a un auditor experimentado entender qué se hizo y con qué resultado, lo que incluye identificar la herramienta, su configuración y la salida utilizada

Ley 22/2015 y RGPD

El deber de secreto y la protección de datos personales favorecen el tratamiento dentro de la firma, aunque no eximen de controles de acceso, registro y conservación

Reglamento (UE) 2024/1689 de IA

La auditoría de cuentas no figura entre los usos de alto riesgo del anexo III. Para la firma, como usuaria («responsable del despliegue»), lo más relevante es la obligación de alfabetización en IA de su personal, vigente desde febrero de 2025 y matizada por el Reglamento (UE) 2026/1744 (ómnibus digital), que aplaza al 2 de diciembre de 2027 las obligaciones de alto riesgo del anexo III

ISO/IEC 42001:2023

Norma certificable de sistema de gestión de la IA. No es obligatoria, pero ofrece una estructura reconocida de políticas, evaluación de impacto, controles y mejora continua

La conclusión práctica es que el uso de IA local encaja en el marco actual siempre que se trate como cualquier otra herramienta de auditoría: aprobada, probada, documentada y supervisada.

Un marco de gobierno práctico para la firma

Antes de usar IA local en encargos reales, una firma de auditoría debería tener resueltos, como mínimo, estos siete puntos:

1.       Inventario y aprobación. Un registro de modelos aprobados con su versión, licencia, origen de descarga y usos autorizados. Ningún modelo entra en un encargo sin pasar por ese registro.

2.       Casos de uso clasificados por riesgo. Distinguir entre usos de apoyo (resumir, redactar borradores, priorizar) y usos que alimentan evidencia (extraer cláusulas, señalar asientos). Los segundos requieren validación previa y revisión reforzada.

3.       Validación antes del uso. Probar cada caso de uso con documentos cuyo resultado correcto ya se conoce y medir aciertos, omisiones y falsos positivos. Repetir la prueba cuando cambie el modelo o la configuración.

4.       Trazabilidad en los papeles. Conservar la instrucción utilizada, los documentos de entrada, la versión del modelo, los parámetros y la salida, junto con la evidencia de la revisión realizada.

5.       Separación de funciones del modelo. El modelo lee, clasifica y redacta; los cálculos los hace código determinista y las conclusiones las firma el auditor.

6.       Seguridad del entorno. Equipo sin salida a internet o con salida controlada, control de accesos por encargo, cifrado y una política de borrado alineada con la de conservación de papeles de trabajo.

7.       Formación y supervisión. Formar al equipo en cómo falla la IA, no solo en cómo se usa, y revisar periódicamente su aplicación dentro del seguimiento del sistema de gestión de la calidad.

Este marco no exige grandes inversiones. Exige, sobre todo, decidir por escrito qué se permite, cómo se comprueba y quién responde.

La diferencia no está en el modelo

La IA local no cambia los fundamentos de la auditoría; cambia el coste de leer, clasificar y cruzar información. Bien gobernada, permite dedicar más horas al juicio profesional y menos a tareas mecánicas, sin comprometer la confidencialidad del cliente.

Mal gobernada, introduce un riesgo nuevo y difícil de detectar: evidencia aparentemente sólida que nadie ha verificado. La diferencia entre ambos escenarios no está en el modelo elegido, sino en los controles que la firma establece a su alrededor. Las firmas que empiecen ahora, con casos acotados y un gobierno claro, llegarán mejor preparadas cuando las nuevas normas del IAASB entren en vigor.

Si su firma está valorando dar este paso, podemos ayudarle a elegir los primeros casos de uso, validar las herramientas y preparar la documentación para que el uso de IA resista una revisión de calidad.

Fuentes

•         IAASB, Exposure Draft: Audit Evidence and Risk Response, agosto de 2026.

•         Cuatrecasas, Digital Omnibus on AI has been published, julio de 2026.

•         Gibson Dunn, EU AI Act Omnibus Agreement: Postponed High-Risk Deadlines and Other Key Changes, mayo de 2026.

•         Ley 22/2015, de 20 de julio, de Auditoría de Cuentas; Reglamento (UE) 2024/1689; ISO/IEC 42001:2023.