Lección 3 · Errores, omisiones y actuación de la aplicación

1. Cuando el control no termina como esperamos

Supongamos que un escáner necesita una dependencia que deja de responder. El contenido puede ser legítimo o peligroso; el error técnico no permite saberlo. Para interpretar lo ocurrido debemos separar tres planos: la comprobación que se realizó, el resultado que devolvió la biblioteca y la actuación posterior de la aplicación.

CerbIA contempla políticas para excepciones de escáneres. No se debe confundir esa gestión con un plan completo de continuidad del servicio. La organización tiene que definir cómo informa al usuario, qué operación se detiene y quién interviene si la situación persiste.

2. Tres políticas con consecuencias distintas

Con fail se propaga el error; block fuerza un resultado inseguro, continuando según fail_fast; skip registra el escáner omitido. Una omisión no se convierte en un análisis sin hallazgos. Políticas de errores del escáner

La elección expresa una tolerancia al riesgo. Detener toda consulta ante un fallo puede proteger información sensible y afectar a la disponibilidad. Continuar sin una comprobación mantiene servicio y deja una brecha. Ninguna política es correcta por su nombre: se justifica según finalidad, consecuencias y medidas complementarias.

La aplicación también debe gestionar una excepción propagada. Capturarla y continuar con la llamada al modelo puede anular la intención de quien eligió fail. Por eso la evaluación necesita observar el recorrido completo.

3. Omisiones por tipo y corte anticipado

La puerta puede omitir un escáner cuando el tipo de contenido conocido no coincide con los tipos aceptados. Un tipo unknown no lo excluye por esa razón. Enrutamiento y omisiones

Existe además una salida anticipada: con fail_fast, un hallazgo BLOCK de riesgo positivo corta cuando su puntuación ponderada individual alcanza el umbral; un error tratado como block también puede hacerlo. No se compara aquí el agregado acumulado. Condiciones del corte anticipado

Deben distinguirse incompatibilidad, error y trabajo no realizado tras el corte. Este último no equivale necesariamente a una entrada explícita en skipped_scanners. Reconstruir cobertura exige mirar también el orden y las condiciones de ejecución.

4. El resultado debe producir un efecto

Obtener is_safe=False e impedir una operación son hechos diferentes. En una integración hay que comprobar que la decisión se toma antes de la llamada o publicación que pretende controlar. La aplicación puede detener, devolver un mensaje o dirigir un caso a una vía autorizada, según su diseño.

El ejemplo LangChain revisado incorpora lógica antes de ejecutar una herramienta y también examina su resultado. Actuación alrededor de una herramienta No debe generalizarse ese comportamiento a cualquier aplicación por haber instalado el paquete.

Un control posterior puede limitar la circulación del resultado, pero no deshace un correo enviado o un registro ya modificado. Este orden temporal es parte del tratamiento del riesgo.

5. Decisión operacional y evidencia

Aplicamos 8.1 a la definición y comprobación de las reglas operativas. En conexión con 5.3, alguien debe tener autoridad para aprobar excepciones y reanudar un servicio detenido. Con 9.1 se seguirá la frecuencia y las consecuencias de errores y omisiones.

Las reglas deben indicar plazo, responsable y condición de retorno cuando se habilite una excepción. Es una propuesta proporcional de operación, no una autorización genérica para ignorar fallos.

6. Ejercicio resuelto: el mensaje ya se envió

Supuesto docente. Un asistente envía un mensaje y después evalúa su contenido. La puerta devuelve resultado inseguro. El equipo concluye que el envío estuvo bloqueado.

Solución. La evaluación posterior acredita una señal, no la prevención del envío. Solicitaríamos evidencia del orden de las llamadas y del mensaje efectivamente publicado. La medida propuesta es situar la evaluación pertinente antes de publicar y comprobar que el resultado inseguro impide la operación.

Si el escáner falla con skip, hay que registrar la ausencia de esa comprobación y aplicar la regla aprobada para esa operación. No podemos denominar ese caso «texto revisado y seguro».

7. Qué se autoriza y quién responde

La autorización operacional concreta cómo tratar resultado inseguro, excepción y omisión. Desarrollo demuestra el efecto, operación atiende fallos y la autoridad del riesgo decide las excepciones significativas. Si se incumple un criterio establecido, se investigará el caso y se valorará la acción correspondiente. Un fallo aislado no se etiqueta automáticamente como no conformidad del SGIA sin identificar el requisito o criterio incumplido.