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

Separa los requisitos y fíjate qué tecnología satisface cada uno. Crear un ticket, reunir los logs relevantes y sugerir un playbook son tres acciones en tres sistemas distintos, y eso es orquestación. Hacerlo automáticamente cuando se dispara una alerta de severidad alta es automatización impulsada por IA. Dejar la decisión final en manos de un analista es validación human-in-the-loop. Una plataforma SOAR — security orchestration, automation and response — es la categoría creada exactamente para esa combinación: 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 dispara manualmente durante una investigación.

Cada alternativa deja fuera uno de los requisitos. Las reglas de correlación estáticas detectan y alertan, pero no actúan, así que no se abre ningún ticket ni se recoge ningún log. Un chatbot sin integraciones puede conversar sobre un incidente, pero no llega al sistema de tickets ni al almacén de logs, así que nada de lo que sugiera se puede ejecutar. Un runbook manual impulsado por trabajos programados no es ni orientado a eventos ni adaptativo, porque se ejecuta por temporizador sin importar lo que haya pasado y una persona sigue realizando cada paso.

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

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.

El objetivo 1.2 enumera los conceptos de procesamiento de datos esenciales para la seguridad de los datos en IA: limpieza de datos, verificación, lineage, integridad, provenance, augmentation y balancing. Data provenance registra el origen y la propiedad de los datos, mientras que data lineage rastrea su movimiento y sus transformaciones a lo largo de la pipeline; juntos establecen la confiabilidad y respaldan las auditorías y la investigación de incidentes. Esto importa 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 provenance/lineage con augmentation (crear datos sintéticos), balancing (corregir el desbalance de clases) ni watermarking (incrustar marcas de propiedad o detectar contenido generado por IA). Consejo para el examen: 'de dónde vinieron los datos y cómo se transformaron' equivale a provenance y lineage.

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.