CompTIA SecAI+ — Preguntas de práctica y simulacro de examen

El EU AI Act es una legislación emblemática que establece un marco regulatorio basado en riesgo para la inteligencia artificial. Clasifica los sistemas de AI en cuatro niveles de riesgo: riesgo inaceptable (prohibido directamente, como los sistemas de puntuación social), riesgo alto (sujeto a requisitos estrictos, incluidas evaluaciones de conformidad, como AI en contratación o aplicación de la ley), riesgo limitado (obligaciones de transparencia, como chatbots que deben revelar que son AI) y riesgo mínimo (sin requisitos específicos, como filtros de spam). Las organizaciones que implementan AI en la UE o procesan datos de ciudadanos de la UE deben cumplir con los requisitos del nivel correspondiente. La Ley también incluye disposiciones para modelos de AI de propósito general, como los modelos de lenguaje grandes. Entender la clasificación de riesgos del EU AI Act es fundamental para el examen SecAI+ porque representa el enfoque regulatorio más completo para la gobernanza de AI a nivel global. Consejo de examen: el EU AI Act tiene cuatro niveles de riesgo: recuerda la jerarquía desde inaceptable hasta mínimo.

Dos requisitos tienen que cumplirse con un solo control, y eso reduce el campo rápidamente. La atribución de costos necesita contabilidad por consumidor; el aislamiento de reparto justo necesita un techo por consumidor. Una política de límite de tokens en el gateway entrega ambas cosas, porque aplica límites por consumidor de la API en función del consumo de tokens y te deja fijar una tasa de tokens por minuto junto con una cuota sobre un periodo más largo, asociada a algo que identifique a quien llama, como una clave de suscripción.

Los tokens son la unidad correcta. Tanto el costo como la capacidad del backend en un modelo de lenguaje escalan con los tokens y no con la cantidad de solicitudes, así que un simple límite de solicitudes por minuto es una mala aproximación: un único prompt muy largo puede consumir más capacidad que mil cortos y aun así pasar una verificación de tasa de solicitudes. Llevar el contador por consumidor es lo que convierte una válvula de seguridad global en aislamiento, porque un equipo que llega a su techo queda limitado sin tocar el margen de nadie más.

Los distractores resuelven otros problemas. Un filtro de temas denegados es un control de seguridad de contenido y no mide nada. El caching semántico reduce las llamadas al backend para prompts repetidos, lo que ayuda al costo promedio pero no garantiza nada sobre equidad ni atribución. Una ventana de contexto más grande aumenta cuánto puede consumir una sola solicitud, lo que empeora el riesgo de inanición en lugar de mejorarlo.

Consejo de examen: cuando una pregunta sobre gateways combina costo con capacidad, busca el control cuya unidad son los tokens y cuyo alcance es la clave de consumidor.

Separa los requisitos y fíjate qué tecnología cumple cada uno. Crear un ticket, recopilar los logs relevantes y sugerir un playbook son acciones en distintos sistemas, es decir, orquestación. Ejecutar esos pasos automáticamente cuando se dispara una alerta de alta severidad es automatización activada por eventos. Sugerir el playbook más pertinente a partir del contexto de la alerta es donde la asistencia de IA aporta valor. Dejar la decisión final en manos de un analista es validación con intervención humana (human-in-the-loop). Los analistas confirman las acciones de alto impacto, pero no necesitan aprobar cada paso rutinario. Una plataforma SOAR (security orchestration, automation and response) pertenece a la categoría diseñada para esta combinación. Sus playbooks son conjuntos preconfigurados de acciones de remediación que se ejecutan automáticamente cuando una alerta o un incidente coincide con una regla, o que un analista activa manualmente durante una investigación.

Cada alternativa deja fuera al menos un requisito. Las reglas de correlación estáticas, por sí solas, detectan y alertan, pero nada en esa opción abre un ticket ni recopila logs. Un chatbot sin integraciones puede conversar sobre un incidente, pero no puede acceder al sistema de tickets ni al almacén de logs, así que no puede realizar por sí mismo ninguno de esos pasos. Un runbook basado en tareas programadas no responde a eventos ni se adapta. Las tareas se ejecutan según un temporizador sin importar lo que haya ocurrido, y los pasos manuales siguen esperando a una persona.

Consejo para el examen: lee los verbos del enunciado. Detectar apunta al monitoreo, orquestar y remediar apuntan a herramientas de respuesta, y un punto de decisión humana explícito te indica que la respuesta correcta mantiene al analista en el ciclo en lugar de eliminarlo.

El objetivo 1.2 enumera conceptos de procesamiento de datos esenciales para la seguridad de los datos de IA: limpieza, verificación, linaje, integridad, procedencia, aumento y balanceo de datos. La procedencia de los datos registra su origen y su propiedad, mientras que el linaje de datos rastrea su movimiento y sus transformaciones a lo largo del pipeline; juntos aportan la evidencia documentada necesaria para evaluar la confiabilidad y respaldar auditorías e investigaciones de incidentes. Esto es importante para la seguridad porque los datos envenenados o manipulados son mucho más fáciles de detectar cuando el origen y el historial están documentados y son verificables. No confundas procedencia/linaje con aumento (crear datos sintéticos), balanceo (corregir el desequilibrio entre clases) ni marcas de agua (incrustar marcas de propiedad o detectar contenido generado por IA). Consejo para el examen: “¿de dónde vienen los datos y cómo se transformaron?” equivale a procedencia y linaje.