CRITERIO 1

Seguridad, privacidad y control desde el diseño.

Diseñamos sistemas de IA y automatización con controles proporcionales al proceso, los datos y las consecuencias de un error.

Conocer el enfoque
Ver la matriz de control

Los controles ayudan a gestionar riesgos y generar evidencia. No garantizan por sí solos el cumplimiento ni sustituyen la revisión jurídica o especializada.

Matriz de control
RiesgoControlEvidenciaResponsable
Uso fuera de alcancePropósito, límites y usos aceptablesPolítica y excepcionesDueño del proceso
Datos personalesMinimización y base jurídicaInventario y retenciónPrivacidad
Resultado erróneoPruebas y revisión humanaResultados y seguimientoResponsable profesional
Acceso indebidoMínimo privilegio y revisiónRegistro de accesosSeguridad
Fallo operativoRespaldo y continuidadPruebas e incidentesOperaciones

Controlar significa saber qué puede ocurrir y quién decide.

Proporcionalidad

El nivel de control depende del proceso, los datos y las consecuencias de un error.

Transparencia

Se documenta qué hace el sistema, qué datos usa y dónde interviene una persona.

Responsabilidad

Cada actividad tiene un responsable identificado, no un sistema anónimo.

Privacidad desde el diseño

Los datos personales se consideran desde el primer análisis, no al final.

Mejora continua

Los controles se revisan y ajustan a medida que cambian el sistema y su contexto.

Un mismo objetivo, controles diferentes.

Organizativos

  • Políticas y usos aceptables
  • Evaluación de riesgos
  • Gestión de proveedores
  • Roles y responsabilidades
  • Procedimiento de escalado
  • Formación del equipo

Técnicos

  • Gestión de identidad y accesos
  • Permisos y mínimo privilegio
  • Pruebas antes de producción
  • Registros de actividad
  • Copias de seguridad
  • Recuperación ante incidentes
  • Entornos separados
  • Control de cambios

Humanos

  • Revisión de resultados
  • Capacidad de detener el sistema
  • Comunicación de incidencias
  • Mejora a partir de la experiencia

El control acompaña al sistema hasta su retirada.

1

Análisis

  • Identificación de riesgos y datos implicados
  • Definición de propósito y límites

2

Diseño

  • Arquitectura de permisos y accesos
  • Privacidad desde el diseño

3

Pruebas

  • Casos de prueba funcionales y de excepción
  • Revisión humana antes de producción

4

Despliegue

  • Entornos separados y control de cambios
  • Registro de actividad desde el inicio

5

Operación

  • Monitorización y respaldo continuo
  • Gestión de incidencias

6

Retirada

  • Cierre ordenado de accesos y datos
  • Documentación del histórico

Cuatro áreas que deben funcionar juntas.

Datos y accesos

Los datos se clasifican, se minimizan y se protegen con cifrado y seudonimización cuando proceda. Los accesos se limitan a quien los necesita y se revisan de forma periódica.

Revisión humana

Los resultados relevantes se revisan antes de usarse. La intervención especializada se activa cuando proceda, según el riesgo y las consecuencias del proceso.

Incidencias y excepciones

Cada incidencia se registra, se analiza y se documenta. Las excepciones a la política se autorizan de forma explícita, nunca por omisión.

Proveedores y cambios

Los proveedores externos se evalúan antes de integrarse. Los cambios en el sistema siguen un control de versiones y una validación previa a su aplicación.

Cada actividad necesita dueño y evidencia.

A = aprueba, R = ejecuta, C = consulta. Esta matriz es orientativa: los roles reales se ajustan a la estructura de cada organización y no constituyen una asignación definitiva.
ActividadAprueba (A)Ejecuta (R)Consulta (C)
Definir propósito y alcanceDueño del proceso (A)Equipo técnico (R)Responsable profesional (C)
Evaluar riesgosResponsable profesional (A)Equipo técnico (R)Privacidad (C)
Definir controlesEquipo técnico (A)Equipo técnico (R)Dueño del proceso (C)
Validar antes de producciónResponsable profesional (A)Equipo técnico (R)Dueño del proceso (C)
Gestionar incidenciasSeguridad (A)Equipo técnico (R)Dueño del proceso (C)
Autorizar retiradaDueño del proceso (A)Equipo técnico (R)Responsable profesional (C)

Los controles técnicos apoyan el cumplimiento; no lo certifican.

Estos controles se diseñan como buena práctica de gobierno de sistemas. No sustituyen el análisis normativo de cada organización.

Criterio Uno diseña e implanta controles dentro del alcance contratado. La organización conserva sus obligaciones y debe contar con asesoramiento jurídico o especializado cuando proceda.

PREGUNTAS FRECUENTES

Antes de revisar un sistema

Preguntas habituales sobre el alcance real de estos controles.
No. Ayudan a gestionar riesgos y a generar evidencia, pero el cumplimiento depende del análisis normativo completo de cada organización, con asesoramiento jurídico cuando proceda.
Sí. El mismo enfoque de capas organizativas, técnicas y humanas aplica a cualquier automatización que trate datos o tome decisiones con impacto en personas o procesos.
Depende de la actividad. La matriz de responsabilidades orientativa distingue quién aprueba, quién ejecuta y a quién se consulta, pero la asignación final la define cada organización.
No fijamos una frecuencia estándar. Se revisan cuando cambia el sistema, el contexto normativo o los riesgos identificados, y de forma periódica según el nivel de exposición.
Se evalúan antes de integrarse y se revisan de forma periódica. Los cambios que introducen se someten al mismo control de versiones que el resto del sistema.
Generamos la documentación de los controles dentro del alcance contratado. La organización conserva la responsabilidad de sus políticas y su marco de cumplimiento.

Revisemos dónde necesita control tu sistema.

Analizamos el proceso, los datos y los puntos donde falta un control claro o un responsable identificado.

Revisar un sistema
Ver nuestro método
Sin promesas de cumplimiento automático ni seguridad absoluta.