La primera vez que alguien te dice que tu IA necesita una auditoría, rara vez suena como una sugerencia amistosa. La petición suele venir de un miembro del consejo, del equipo de seguridad de un gran cliente o de un regulador, y casi siempre llega con una fecha límite. Así que aquí tienes la respuesta directa que buscas: qué es una auditoría de IA, qué abarca, qué tipo podrías necesitar, quién la necesita y qué esperan de ti las normativas de IA actuales.
Una auditoría de IA es una revisión estructurada y basada en evidencias de un sistema de inteligencia artificial (IA) y de la organización que lo opera, medida frente a criterios técnicos, operativos, éticos y legales claros. Examina los datos, el comportamiento del modelo, el software que lo rodea, la seguridad, la supervisión humana y la gobernanza, y plantea la única pregunta que una demo de producto nunca hace: ¿está este sistema haciendo de verdad el trabajo para el que se construyó, de forma segura y a un coste que tenga sentido?
Esa última pregunta es lo que separa una auditoría de verdad de un ejercicio de marcar casillas. Muchas revisiones confirmarán si tu IA está legalmente en orden. Muchas menos preguntan si es fiable, si la gente confiará en ella y si está justificando lo que cuesta.
Lo que una auditoría de IA no es
Antes de seguir adelante, aclaremos cierta confusión, porque a esta expresión se le cuelgan al menos tres cosas que no tienen nada que ver entre sí:
- Una auditoría de oportunidades de IA busca lugares de tu negocio donde podría introducirse la IA.
- Una auditoría hecha con herramientas de IA usa software para ayudar a una persona a revisar facturas o contratos, lo que en realidad la convierte en una auditoría interna o financiera más inteligente.
- Una auditoría financiera tradicional toca de vez en cuando un producto de IA, aunque su foco sigue puesto en las cuentas de la empresa más que en la IA en sí.
Este artículo no trata de ninguna de ellas. Nuestro tema es la revisión de un sistema de IA que ya operas o que estás a punto de lanzar.
Incluso dentro de ese significado más estricto, la forma exacta de una auditoría depende de los criterios que fijes, de las evidencias disponibles, del acceso que se dé a los revisores y del nivel de garantía que realmente necesites. Una comprobación rápida antes de una demo y una revisión completa previa al lanzamiento son ambas auditorías de IA, y son muy distintas entre sí. Esa misma disciplina es la que Redwerk aporta a su trabajo de auditoría de software independiente, donde el objetivo es una imagen clara y honesta de si un sistema es seguro para confiar en él.
Por qué una auditoría de IA importa más que una casilla de cumplimiento
Es tentador archivar una auditoría de IA bajo «papeleo» y pasar página. Los números defienden con fuerza que no lo hagas.
A finales del año pasado, Gartner constató que al menos la mitad de los proyectos de IA generativa se habían abandonado tras la fase de prueba de concepto, hundidos por una mala calidad de los datos, controles de riesgo débiles, costes desbocados o un valor de negocio que nunca acababa de aparecer. Es una subida marcada frente al aproximadamente 30 % que la firma había predicho al principio. Puedes leer los detalles en el análisis de Gartner sobre por qué fracasan los proyectos de IA generativa. La lección no es que una parte fija de la IA esté condenada, sino que el mismo puñado de problemas sigue hundiendo trabajos por lo demás prometedores, y cada uno de ellos es algo que una auditoría está diseñada para detectar.
Vemos las mismas historias una y otra vez. Una demo deslumbra a todos porque corrió sobre datos de prueba impecables, y luego tropieza en cuanto llegan solicitudes reales de clientes. Una puntuación de benchmark parece fantástica, pero nadie comprobó si esas preguntas de prueba se parecen a lo que los usuarios realmente escriben. Los prompts y los ajustes se retocan sobre la marcha sin registro de quién cambió qué ni por qué. Las facturas de la nube y de los tokens trepan en silencio hasta que las cuentas de todo el proyecto dejan de salir. La revisión humana figura en el documento de política, pero no existe en ninguna parte del producto real.
Muchos de estos problemas son justamente la razón por la que tantas implantaciones prometedoras nunca superan la fase de prueba, un patrón que hemos desgranado en por qué los pilotos de IA empresarial se estancan antes de producción. Una auditoría convierte esas preocupaciones vagas y persistentes en una lista concreta y priorizada sobre la que puedes actuar antes de que se conviertan en un titular o en una avalancha de solicitudes de reembolso.
Qué implica auditar la IA: las tres capas
Cuando la gente pregunta qué implica auditar la IA, ayuda pensar en el sistema como tres capas, porque a los problemas les gusta esconderse en sitios distintos según dónde mires:
- Organización y gobernanza abarca el lado humano del sistema: quién es dueño de la IA, qué políticas rigen su uso, cómo se aprueban las decisiones, cómo se gestionan los incidentes y si alguien está de verdad vigilando el sistema una vez que se pone en marcha. Un modelo brillante sin dueño ni supervisión es un riesgo esperando a aflorar.
- Modelo y datos es donde la revisión comprueba lo preciso que es realmente el modelo, si los datos de entrenamiento y de prueba valen algo, si el sistema trata con equidad a distintos grupos de personas, si puedes explicar las decisiones que toma y si su comportamiento deriva con el tiempo a medida que el mundo cambia a su alrededor.
- Aplicación y sistema en producción es el software que envuelve al modelo. Abarca cómo el sistema recupera información, gestiona lo que escriben los usuarios, se conecta a tus demás herramientas, se protege del uso indebido, registra lo que ocurre cuando algo falla y cuánto cuesta mantenerlo todo en marcha. Un modelo seguro y preciso aún puede provocar el caos si el software que lo sostiene tiene fugas o es frágil.
Cuánto profundiza una auditoría en cada capa depende de cómo se use el sistema, cuánto riesgo conlleva, en qué punto de su ciclo de vida se encuentra, cuánto acceso tienen los revisores y qué normativas aplican. Una herramienta interna de bajo riesgo y un sistema de cara al cliente que toma decisiones reguladas exigen niveles de escrutinio muy distintos.
Los principales tipos de auditoría de IA
En la práctica, «auditoría de IA» es un paraguas sobre varios tipos de revisión. Estos son los principales, descritos por el riesgo de negocio que cada uno está diseñado para sacar a la luz más que por la maquinaria técnica que hay detrás.
Auditoría del rendimiento del modelo
Esto comprueba si el modelo funciona de verdad una vez que personas reales empiezan a usarlo, no solo si lucía bien en la demo. Examina patrones de error, respuestas inventadas o «alucinadas», casos límite incómodos y si el rendimiento se degrada en silencio con el tiempo. La verdadera pregunta nunca es si el sistema bordó una prueba, sino si aguanta cuando los clientes lo usan de maneras que nadie anticipó.
Auditoría de calidad y privacidad de los datos
Un sistema de IA es tan fiable como los datos que hay detrás. Esta revisión rastrea de dónde vinieron los datos, si tenías derecho a usarlos, si reflejan el uso del mundo real y si podría filtrarse información sensible o conservarse más tiempo del debido. Los datos débiles son el culpable silencioso detrás de un número sorprendente de fallos de IA, y acarrean consecuencias tanto de precisión como legales.
Auditoría de sesgo y equidad
La equidad depende mucho de lo que el sistema haga, así que una buena revisión empieza por definir a quién podría afectar, cómo es el daño y qué es un resultado aceptable. A partir de ahí mide si el sistema trata a esos grupos de forma equilibrada y quién es responsable de arreglar las cosas cuando no lo hace. Equivócate en esto y te enfrentarás a quejas, exposición legal y una pérdida de confianza difícil de recuperar.
Auditoría de seguridad de la IA
Los sistemas de IA abren riesgos que el software tradicional no tiene, desde la inyección de prompts (engañar al modelo con una entrada hábilmente redactada) hasta datos sensibles que se filtran a través del modelo, pasando por agentes de IA a los que se les ha dado más acceso del que deberían. Esta revisión sondea quién puede llegar al modelo y a sus datos, cómo se defiende del uso indebido y qué tan preparado estás para responder cuando algo va mal. Cuando Redwerk auditó el código detrás de Site Compass, una aplicación de mapeo de redes, la arquitectura resultó ser sólida y, aun así, la revisión sacó a la luz problemas de severidad crítica y media, lo que permitió al equipo corregirlos sin ruido y lanzar con confianza en lugar de descubrirlos por las malas en producción.
Auditoría de gobernanza y cumplimiento
Esta es la revisión de papeleo y proceso, y importa más de lo que suena. Examina políticas, propiedad, pasos de aprobación, supervisión humana, documentación y cómo todo se corresponde con las normativas bajo las que caes. También cubre la transparencia: si se informa a los usuarios de que están tratando con una IA, si las decisiones pueden explicarse y si conservas suficiente registro para reconstruir lo que pasó si alguien lo pregunta. Cuando un regulador o un gran cliente quiere que demuestres qué hizo tu sistema y por qué, esta es la capa que te salva.
En la vida real estas rara vez ocurren de forma aislada. La mayoría de los proyectos mezclan varias de ellas, porque los datos, el modelo, el código y la gobernanza se apoyan unos en otros. Esto es especialmente cierto cuando buena parte del software circundante se escribió con asistencia de IA, lo que trae sus propios riesgos de mantenibilidad en el código asistido por IA que conviene comprobar durante la misma revisión.
¿Qué es una auditoría de gobernanza de IA?
Una auditoría de gobernanza de IA comprueba si tu organización tiene controles reales, documentados y seguidos de forma consistente para elegir, construir, desplegar, monitorizar, modificar y, con el tiempo, retirar sistemas de IA. Una auditoría técnica te dice si el sistema funciona. La auditoría de gobernanza mira un nivel más arriba, hacia si las personas y los procesos en torno a ese sistema lo mantienen realmente bajo control.
La razón por la que esto merece nombre propio es que abundan los términos en este terreno que suenan parecido pero significan cosas distintas. Saber cuál necesitas de verdad ahorra tiempo, dinero y no poca confusión.
Auditoría técnica de IA
El modelo, los datos, el software, la seguridad y cómo se comporta el sistema en producción
Auditoría de gobernanza de IA
Políticas, responsabilidades, decisiones, controles y las evidencias que los respaldan
Evaluación de impacto de IA
Los posibles efectos del sistema sobre las personas, sus derechos, la seguridad y la sociedad
Evaluación de conformidad
Demostrar que un sistema cumple requisitos regulatorios concretos
Auditoría de certificación ISO
Una verificación independiente de un sistema de gestión frente a una norma certificable
Auditoría de preparación para la IA
Si la organización está preparada, para empezar, para adoptar o escalar la IA
Aquí cabe una salvedad honesta. Una revisión técnica o de gobernanza de un socio de software como Redwerk te ayuda a preparar evidencias, corregir problemas y prepararte para el cumplimiento, pero no es lo mismo que una certificación formal, una aprobación regulatoria o un dictamen legal. La certificación ISO/IEC 42001, por ejemplo, es voluntaria y solo la conceden organismos de certificación acreditados. Nosotros te ayudamos a llegar preparado. El certificado en sí lo emite el organismo certificador.
Por qué a los reguladores les importa la IA auditable
Los reguladores no exigen auditorías para complicarte la vida. Lo piden porque, cada vez más, puede que necesites demostrar cosas sobre tu IA: para qué se construyó, cómo detectaste y gestionaste sus riesgos, qué datos y pruebas se usaron para hacerla, si un humano puede intervenir y anularla, si registras lo que hace y quién dio el visto bueno para ponerla en marcha. Una auditoría es la forma de reunir esas evidencias antes de que nadie las pida.
La Ley de IA de la UE de un vistazo (última verificación: 21 de julio de 2026)
La Ley de IA de la Unión Europea entró en vigor el 1 de agosto de 2024, y sus normas llegan por oleadas. Las prohibiciones de las prácticas de mayor riesgo y los deberes de alfabetización en IA empezaron en febrero de 2025. Las normas para la IA de propósito general y la estructura de gobernanza de la Ley siguieron en agosto de 2025. A finales de 2025, la Comisión Europea propuso un paquete de simplificación conocido como el Digital Omnibus, que avanzó deprisa este año: el Parlamento Europeo lo respaldó en junio de 2026 y el Consejo dio su aprobación final a finales de ese mes, con la publicación y la entrada en vigor poco después. El resultado práctico para la mayoría de las empresas es más margen de respiro en las obligaciones más pesadas. Los requisitos para los sistemas de alto riesgo ligados a usos concretos, como la contratación o la puntuación crediticia, ahora aplican desde el 2 de diciembre de 2027 en lugar de agosto de 2026, y la IA de alto riesgo integrada en productos regulados pasa a agosto de 2028. Los deberes de transparencia, como avisar a las personas cuando están interactuando con una IA, se mantienen en gran medida en su calendario original de 2026, así que esa presión concreta no ha ido a ninguna parte.
Como estas fechas no dejan de moverse, trata el resumen anterior como una instantánea y confirma la situación actual en la página oficial de la Ley de IA de la Comisión Europea antes de tomar cualquier decisión.
Ese tiempo extra es realmente útil, aunque no es motivo para relajarse. La parte más dura de prepararse, encontrar cada sistema de IA que operas y averiguar qué reglas aplican a cada uno, no se vuelve más fácil por esperar. Tampoco se han suavizado los propios requisitos de alto riesgo: siguen incluyendo la gestión de riesgos a lo largo del ciclo de vida, una gobernanza de datos sólida, documentación, registro, supervisión humana, precisión, robustez, ciberseguridad y monitorización tras el lanzamiento. Las sanciones también son serias, y llegan hasta 35 millones de euros o el 7 % de la facturación anual mundial para las infracciones más graves.
Europa no es el único punto de referencia. En Estados Unidos, el Instituto Nacional de Estándares y Tecnología ofrece un Marco de Gestión de Riesgos de IA voluntario construido en torno a cuatro actividades en lenguaje sencillo: gobernar, mapear, medir y gestionar. Es un esqueleto práctico para estructurar una auditoría incluso donde ninguna ley lo exige. En el plano internacional, está tomando forma una familia de normas ISO, entre ellas ISO/IEC 42001 para sistemas de gestión de IA, ISO/IEC 42005:2025 para evaluaciones de impacto de sistemas de IA e ISO/IEC 42006:2025 para los organismos que auditan y certifican esos sistemas de gestión. Juntas refuerzan una lección útil: probar un sistema, revisar su gobernanza, evaluar su impacto y certificarlo son cuatro ejercicios distintos, y vale la pena saber cuál necesitas de verdad.
¿Quién necesita una auditoría de inteligencia artificial?
Aquí va la respuesta directa: necesitas una auditoría de IA cuando un sistema de IA toca algo que importa, ya sean tus clientes, tus empleados, la seguridad o los derechos de las personas, tus finanzas, una decisión regulada o una promesa que has escrito en un contrato. Si lo peor que puede hacer un sistema es dejarte en evidencia de forma poco trascendente, bastará con una comprobación ligera. En cuanto hay consecuencias reales sobre la mesa, una auditoría en condiciones justifica su coste enseguida.
Eso abarca a más organizaciones de las que imaginas. Las empresas que construyen y venden productos de IA claramente la necesitan. También los negocios que incrustan el modelo de otro en su propio software, junto con las empresas que compran IA a un proveedor y ponen su propio nombre a los resultados. La necesidad es más acuciante para usos de alto impacto o regulados, para equipos que dan el salto de un piloto prometedor a producción plena y para cualquiera que afronte una exigente revisión de seguridad empresarial o se prepare para una inversión, una adquisición o una diligencia debida.
Vale la pena jubilar una idea equivocada: usar el modelo de otro no te libra de responsabilidad. Si has construido un chatbot sobre el modelo de un gran proveedor, sigues siendo dueño de la aplicación que lo rodea, de los datos que le das, de los prompts, de los permisos y de la monitorización. El proveedor se ocupa de su propio modelo. Cómo construyes sobre él, cómo lo alimentas y cómo lo vigilas es de lleno tu responsabilidad.
En cuanto al momento, vale la pena reservar una revisión siempre que se cumpla alguna de estas condiciones:
- Estás a punto de lanzar a producción, o de entrar en un mercado regulado o empresarial.
- Has cambiado el modelo, un proveedor o un conjunto de datos.
- El rendimiento ha empezado a resbalar, o los costes han superado el argumento de negocio.
- Acabas de tener un susto de seguridad o de privacidad.
- Los usuarios empiezan a desconfiar de las decisiones del sistema o a cuestionarlas.
- Un miembro del consejo, una aseguradora, un cliente o un regulador te ha pedido que demuestres tu trabajo.
Lo que realmente recibes: por dentro de un informe de auditoría de IA
Una buena auditoría no termina con un encogimiento de hombros y un vago «parece que va bien en su mayoría». Te entrega un informe que puedes llevar a tu consejo, a tu mayor cliente o a tu equipo de ingeniería y usar de verdad. Uno completo suele darte:
- El alcance de la revisión y los criterios usados para juzgar el sistema
- Un inventario del sistema y de todo aquello de lo que depende
- Una declaración sencilla de lo que se supone que el sistema debe lograr para el negocio
- Las evidencias revisadas y los hallazgos, cada uno valorado por severidad
- Cómo se corresponden esos hallazgos con las normativas o marcos que te aplican
- Los resultados de las pruebas del modelo y del sistema
- Observaciones sobre el rendimiento del negocio y los costes de operación
- Una lista priorizada de correcciones, cada una con un responsable y una fecha objetivo
- Los riesgos que quedan, más límites honestos sobre lo que la auditoría pudo confirmar
- Recomendaciones para repetir pruebas y monitorizar de forma continua
Para hacerlo concreto, aquí tienes el tipo de hallazgo que podría contener un informe, extraído de un patrón con el que nos topamos a menudo:
Los datos de evaluación no reflejan las solicitudes reales
El 72 % de los prompts de prueba son consultas cortas en inglés, mientras que el tráfico de producción incluye consultas largas y multilingües
La precisión reportada exagera lo bien que rinde realmente el sistema
Alto
Reconstruir el conjunto de evaluación en torno a escenarios de producción y grupos de usuarios reales
Hemos visto de primera mano el valor de ese enfoque valorado por severidad. Cuando Complete Network pidió a Redwerk que revisara el backend de su software de gestión de presupuestos antes de que saliera a producción, examinamos la arquitectura, la calidad del código, la seguridad, el manejo de errores y la estructura de la base de datos, y luego ordenamos cada problema por severidad y estimamos las horas necesarias para corregir cada uno. La auditoría de Project Science terminó con la mantenibilidad del software mejorada un 80 % y, algo igual de valioso, con un equipo que sabía exactamente qué estaba a punto de lanzar.
Un área que vale la pena destacar es la supervisión humana. Un informe debería mostrar no solo que se supone que una persona revisa la salida de la IA, sino que la revisión ocurre de verdad en un lugar donde un humano puede verla y actuar sobre ella. Juzgar lo bien que las personas y la IA trabajan realmente juntas es una disciplina en sí misma, y merece atención real en cualquier revisión seria.
Cuando los hallazgos exigen un rework de verdad, ya sea reconstruir un modelo poco fiable o rediseñar el software que lo rodea, ahí es donde entra nuestro trabajo de desarrollo y remediación de IA. Y si prefieres arremangarte y hacer tú mismo una revisión, el paso a paso de reunir evidencias y comprobar cada etapa queda fuera del alcance de este artículo, que deliberadamente se mantiene lejos de la maleza del cómo se hace.
Los límites de una auditoría de IA
Sería deshonesto fingir que una auditoría es una varita mágica, así que dejemos claro lo que no puede hacer. Una auditoría es tan buena como su alcance y las evidencias que se le permite ver. Una revisión hecha en un momento dado no puede prometer que el sistema no derive el mes que viene. Acceso limitado al código, los datos y la configuración significa garantía limitada, así de simple. Pasar una auditoría no garantiza cero errores, y ser legalmente conforme no significa automáticamente que el producto sea bueno para tu negocio. Una puntuación de benchmark deslumbrante sigue sin ser prueba de que el sistema esté listo para usuarios reales. Incluso después de aplicar cada corrección recomendada, tendrás que seguir vigilando el sistema, porque la IA tiene la costumbre de cambiar su comportamiento cuando el mundo a su alrededor cambia.
Nada de eso hace que una auditoría valga menos. Solo significa que una auditoría es un punto de partida potente para mantener la IA fiable, y no un certificado que enmarcas y olvidas.
Si algo de esto te ha dejado preguntándote en voz baja si tu sistema de IA es tan sólido como parece en la demo, esa es precisamente la pregunta que responde una auditoría. Redwerk te da una lectura honesta y basada en evidencias de si tu IA es fiable, segura, defendible y digna de lo que cuesta operarla, junto con una lista clara de qué corregir primero y en qué orden. Ya sea que te dirijas a un gran acuerdo empresarial, te prepares para las normas de la UE o simplemente quieras menos sorpresas antes del lanzamiento, el equipo de auditoría de Redwerk puede echarle un buen vistazo. Llámanos y averigüemos dónde está de verdad tu IA.
Preguntas frecuentes
¿Es obligatoria por ley una auditoría de IA?
No de forma universal. Algunos usos caen bajo normativas como la Ley de IA de la UE que exigen controles y evidencias concretos, mientras que muchos otros no conllevan ninguna obligación legal. Incluso cuando no es obligatoria, una auditoría suele ser la vía más rápida para satisfacer a un cliente cauto, a un inversor o a una aseguradora que quiere pruebas antes de comprometerse.
¿Cuál es la diferencia entre una auditoría de IA y una evaluación de impacto de IA?
Una auditoría mira hacia dentro y pregunta si el sistema funciona, se mantiene bajo control y cumple los criterios que fijaste para él. Una evaluación de impacto mira hacia fuera y pregunta cómo podría afectar el sistema a las personas, a sus derechos y a la sociedad en general. Muchas organizaciones descubren que necesitan ambas, ya que un sistema puede ser perfectamente sólido sobre el papel y aun así causar daño una vez que está en el mundo.
¿Quién puede realizar una auditoría de IA?
Tres tipos de revisor, en realidad. Tu propio equipo puede hacer una comprobación interna, un cliente o socio puede revisarte como parte de su diligencia debida, o un especialista externo puede entrar de forma independiente. Las revisiones independientes suelen tener más peso ante clientes y reguladores, sencillamente porque nadie puede acusarlas de ser blandas con su propio trabajo.
¿Una auditoría de IA requiere acceso al código fuente?
No siempre, aunque el acceso decide cuánto puede probar realmente la auditoría. Una revisión hecha desde fuera puede detectar mal comportamiento, mientras que una revisión más completa que ve el código, los datos y la configuración puede explicar por qué ocurre ese comportamiento y confirmar que las salvaguardas internas son reales y no supuestas.
¿Qué evidencias examina un auditor de IA?
Cambia según el alcance, pero los elementos habituales incluyen la documentación del modelo, muestras de los datos de entrenamiento y de prueba, registros de quién aprobó qué, logs de la actividad del sistema, los prompts y ajustes en uso y los resultados de pruebas anteriores. Cuanto menos tenga que dar por sentado un auditor, más útiles resultan los hallazgos.
¿Cuál es la diferencia entre una auditoría de IA y una revisión de código?
Una revisión de código se centra en el software en sí, en cosas como la legibilidad, la estructura y lo fácil que es mantener el código. Una auditoría de IA lanza una red más amplia, abarcando los datos, el comportamiento del modelo, la seguridad, la gobernanza y si el conjunto entrega un valor de negocio real. Una revisión de código suele ser una pieza útil de una auditoría más amplia más que un sustituto de ella.
¿Cuánto dura una auditoría de IA?
Eso depende de lo grande que sea el sistema, de cuánto acceso puedas conceder y de lo profundo que quieras llegar. Una revisión centrada en una única preocupación puede cerrarse en unos días, mientras que un barrido completo por modelo, datos, software y gobernanza naturalmente lleva más tiempo. Fijar bien el alcance al principio es lo que mantiene honesto el calendario.
¿Qué determina el coste de una auditoría de IA?
Sobre todo el alcance y el acceso. Una comprobación rápida y focalizada cuesta mucho menos que una revisión de arriba abajo de un sistema complejo que afronta exigencias regulatorias estrictas. El nivel de garantía que necesitas, cuántos sistemas hay implicados y cuánta documentación ya tienes a mano empujan la cifra hacia arriba o hacia abajo.
¿Puede automatizarse por completo una auditoría de IA?
Las herramientas automatizadas ayudan, y son rápidas escaneando problemas conocidos, pero no pueden juzgar si un sistema encaja de verdad con su propósito, si un compromiso de equidad es aceptable o si el argumento de negocio sigue cuadrando. Las decisiones de criterio que hacen que valga la pena una auditoría siguen necesitando a personas con experiencia en el circuito.
¿Con qué frecuencia debe auditarse un sistema de IA?
No hay un calendario fijo, y una casilla marcada una vez al año rara vez encaja con la IA. El enfoque sensato ata las revisiones al riesgo y al cambio, de modo que los sistemas de mayor riesgo se revisen con más regularidad y cualquier cambio significativo en el sistema se gane una revisión nueva. Los momentos concretos que deberían motivar una se cubren antes en este artículo.
Descubre cómo realizamos una auditoría en una app de mapeo de redes, comprobando la salud de la base de código y la seguridad