Human Oversight Requirements Implementation Guide — EU AI Act Article 14

Disclaimer: This is guidance only, not legal advice. Consult qualified legal counsel for your specific compliance obligations.

Template provided by VORLUX AI | vorluxai.com

What Article 14 Requires

Article 14 of the EU AI Act mandates that high-risk AI systems be designed and developed in such a way that they can be effectively overseen by natural persons during the period of use. This is not merely a policy requirement — it must be built into the system architecture and operational procedures.

The Four Core Article 14 Obligations

Obligation	Article Ref	What It Means
Meaningful oversight by design	14(1)	System must be technically capable of being overridden, stopped, or corrected
Appropriate interface for oversight	14(2)	Tools and information must enable the human overseer to actually understand and control the system
Overseer competency	14(3)	Persons assigned to oversee the system must have the knowledge and authority to do so effectively
Override and stop capability	14(4)	Overseer must be able to intervene in real time and override or interrupt system operation

Part 1 — Oversight Mechanism Design

1.1 System-Level Requirements

Before deployment, confirm the following are implemented in the AI system:

Interpretability and Transparency

System outputs include confidence scores or uncertainty estimates where technically feasible
System provides human-interpretable explanations for outputs (appropriate to the risk level and use case)
System flags cases where it is operating near or outside its design envelope
System surfaces the most relevant input features or factors contributing to each decision

Oversight Interface

A dedicated oversight interface exists (dashboard, API, or operator console)
The interface shows current system status (running, paused, degraded, error)
The interface displays input data, model output, confidence, and key decision factors
The interface provides access to audit logs
The interface is accessible to oversight personnel without specialist technical knowledge

Override and Control Capabilities

Manual override of individual AI decisions is possible in real time
System-wide pause / stop function is available and accessible within ____ seconds
Outputs can be flagged for human review before taking effect (if pre-decision mode is appropriate)
Revocation / reversal of AI decisions is possible for a defined window after output: ____ hours/days
Fallback to manual process is documented and tested

Technical Architecture Controls

Control	Implementation	Test Date	Test Result
Emergency stop button / API endpoint	`___________`	`____-__-__`	☐ Pass ☐ Fail
Decision audit trail (tamper-evident)	`___________`	`____-__-__`	☐ Pass ☐ Fail
Real-time output monitoring	`___________`	`____-__-__`	☐ Pass ☐ Fail
Human override logging	`___________`	`____-__-__`	☐ Pass ☐ Fail
Rollback capability	`___________`	`____-__-__`	☐ Pass ☐ Fail

1.2 Oversight Mode Matrix

Define when human oversight is active and what level is required:

Operational Mode	Description	Oversight Level Required	Trigger
Human-in-the-Loop	Every decision reviewed before effect	Full review of each output	High-stakes decisions; low-volume contexts
Human-on-the-Loop	AI acts; human monitors and can override	Sampling + anomaly alerts	Medium-volume; reversible decisions
Human-over-the-Loop	AI operates autonomously; periodic human audit	Audit of sample + KPI dashboard	High-volume; lower-stakes; reversible
Emergency Override	Human takes full manual control	Complete manual operation	Incident; system anomaly; legal requirement

Current Operational Mode for this system: ___________________________

Rationale for selected mode (must be proportionate to risk):

[Explain why this oversight mode is appropriate given the system's risk profile,
decision reversibility, volume, and stakes involved]

Part 2 — Competency Requirements for Oversight Personnel

2.1 Roles and Responsibilities

Define oversight roles appropriate to your system:

Role	Responsibility	Authority Level	Minimum Staffing
AI System Operator	Day-to-day use; first-line monitoring	Can flag for review; cannot override model	`___` FTE
Human Overseer	Monitors outputs; can override individual decisions	Full override of individual outputs	`___` FTE
Responsible AI Officer	System-level accountability; escalation authority	Can pause or stop system; escalates incidents	`___` FTE
System Administrator	Technical monitoring; infrastructure controls	Can stop system; restart; rollback	`___` FTE

2.2 Competency Framework

Article 14(3) requires oversight persons to have the necessary competence, training, and authority and be given appropriate access to information.

Minimum Competency Requirements

Competency Area	Human Overseer	Responsible AI Officer
Understanding of AI system purpose and limitations	Required	Required
Ability to interpret system outputs and confidence scores	Required	Required
Domain knowledge relevant to system’s decisions	Required	Desirable
Understanding of when to escalate vs. intervene	Required	Required
Knowledge of override procedures	Required	Required
Understanding of prohibited AI practices (Art. 5)	Required	Required
Knowledge of reporting obligations	Desirable	Required
Basic AI/ML literacy	Desirable	Required

Competency Assessment Checklist

For each person assigned to human oversight, confirm:

Role-specific job description updated to include AI oversight responsibilities
Competency baseline assessment completed
Required training completed (see Section 2.3)
Competency confirmed via assessment or sign-off
Access to relevant information and systems granted
Oversight authority formally delegated in writing
Emergency contact details and escalation path provided

Oversight Personnel Register:

Name	Role	Competency Confirmed	Training Date	Authority Granted	Review Date
`___________`	`___________`	☐ Yes ☐ No	`____-__-__`	☐ Yes ☐ No	`____-__-__`
`___________`	`___________`	☐ Yes ☐ No	`____-__-__`	☐ Yes ☐ No	`____-__-__`
`___________`	`___________`	☐ Yes ☐ No	`____-__-__`	☐ Yes ☐ No	`____-__-__`

2.3 Training Programme

Design a training programme appropriate to the system and the oversight role:

Core Training Modules (all oversight personnel)

Module	Content	Duration	Delivery	Assessment
AI System Overview	Purpose, capabilities, limitations, design envelope	`___ hrs`	☐ Classroom ☐ E-learning ☐ Practical	☐ Test ☐ Sign-off
Output Interpretation	How to read outputs, confidence scores, flags, explanations	`___ hrs`	☐ Classroom ☐ E-learning ☐ Practical	☐ Test ☐ Sign-off
Oversight Procedures	When and how to intervene, override, escalate	`___ hrs`	☐ Classroom ☐ E-learning ☐ Practical	☐ Test ☐ Sign-off
Override Operations	Practical use of override controls; system stop	`___ hrs`	☐ Classroom ☐ E-learning ☐ Practical	☐ Test ☐ Sign-off
Incident Reporting	What to report, to whom, within what timeframe	`___ hrs`	☐ Classroom ☐ E-learning ☐ Practical	☐ Test ☐ Sign-off
Legal and Ethical Obligations	EU AI Act basics; prohibited practices; rights of affected persons	`___ hrs`	☐ Classroom ☐ E-learning ☐ Practical	☐ Test ☐ Sign-off

Training Refresher Frequency: ☐ Quarterly ☐ Biannually ☐ Annually ☐ Trigger-based

Trigger Events for Ad-Hoc Training:

Significant model update or version change
Incident or near-miss involving the AI system
Change in the oversight role or operating environment
New regulatory guidance published
Results of audit identify competency gap

Part 3 — Override Procedures

3.1 Override Decision Framework

Human overseers must know when to intervene. Provide clear guidance:

Mandatory Override Scenarios (overseer MUST intervene):

Scenario	Detection Method	Override Action	Documentation Required
System confidence score below threshold (`< ____`)	Dashboard alert	Refer to manual review	Yes — log reason and outcome
Output affects a protected characteristic (Art. 10)	Flag in output	Pause and escalate	Yes — immediate log + senior sign-off
System operating outside design envelope	Out-of-distribution alert	Stop and notify admin	Yes — incident report
User / affected person objects or appeals	User request	Pause and human review	Yes — record objection and decision
Regulatory or legal query about a decision	External request	Pause outputs; flag for legal	Yes — log all communications
Serious incident triggered	Alert / report	Emergency stop	Yes — full incident report

Discretionary Override Scenarios (overseer MAY intervene):

Scenario	Guidance
Output “feels wrong” to the overseer based on domain knowledge	Investigate; compare with recent outputs; escalate if concern persists
Unusual pattern of outputs across a session	Review session logs; compare with baseline; consider temporary pause
Contextual information not available to the AI suggests different outcome	Document; override if justified; submit feedback to system owners
Affected person provides additional information	Consider new information; override if it would materially change the output

3.2 Step-by-Step Override Procedure

HUMAN OVERRIDE STANDARD PROCEDURE
==================================

Step 1: IDENTIFY
  - Note the system output and the reason for concern
  - Record the decision ID, timestamp, and affected person/case reference

Step 2: ASSESS
  - Review available evidence (inputs, confidence score, explanation)
  - Apply domain knowledge and context
  - Consult with a colleague if unsure (do not delay if harm is imminent)

Step 3: DECIDE
  - If overriding: determine the correct outcome
  - If pausing: decide whether to refer to another overseer or escalate
  - If accepting output: document your agreement and rationale

Step 4: ACT
  - Use the override interface to record your decision
  - Apply the overridden outcome in the relevant system/process
  - Note any system feedback or acknowledgement

Step 5: DOCUMENT
  - Complete the override log (Section 3.3 below)
  - Submit feedback to the AI system team if the override suggests a systematic issue
  - Report to supervisor if the override indicates a material system problem

Step 6: FOLLOW UP
  - Check that overridden outcome was applied correctly
  - If escalation was required, confirm escalation was received and is being addressed
  - Contribute to periodic override pattern review (see Section 4.3)

3.3 Override Log Template

Maintain a log of all overrides. This log forms part of the audit trail required under Art. 12.

Field	Value
Override ID	`OVR-____-____-____`
Date and Time	`____-__-__` `__:__:__`
AI System Version	`___`
Decision / Output ID	`___________________________`
Overseer Name	`___________________________`
Original AI Output	`___________________________`
AI Confidence Score	`____%`
Reason for Override	`___________________________`
Human Decision	`___________________________`
Evidence Considered	`___________________________`
Outcome Applied	☐ Yes ☐ No — Reason: `___`
Escalated?	☐ Yes → Escalation ID: `___` ☐ No
Supervisor Notified?	☐ Yes ☐ No
Feedback Submitted to AI Team?	☐ Yes ☐ No
Follow-Up Required?	☐ Yes — Action: `___` ☐ No

3.4 Emergency Stop Procedure

EMERGENCY STOP PROCEDURE
=========================

USE WHEN: AI system is producing harmful outputs, behaving unexpectedly, or
involved in a serious incident requiring immediate cessation of operation.

STEP 1: ACCESS EMERGENCY STOP
  Option A: Dashboard → [EMERGENCY STOP] button (red)
  Option B: API call: POST /api/v1/system/emergency-stop (requires admin token)
  Option C: Contact system administrator at: ___________________________
            Phone: ___________________________  (24/7)

STEP 2: CONFIRM STOP
  - Verify system status shows "HALTED" in dashboard
  - Confirm no new outputs are being generated
  - Alert team members that system is stopped

STEP 3: NOTIFY IMMEDIATELY
  - Responsible AI Officer: ___________________________
  - System Administrator: ___________________________
  - Department Head: ___________________________

STEP 4: PRESERVE EVIDENCE
  - Do not restart the system without authorisation
  - Export and preserve logs from the period of concern
  - Document what you observed and when

STEP 5: INCIDENT REPORT
  - Complete full incident report within ___ hours
  - Reference: Incident Reporting Procedure [Doc: ___________]

RESTART AUTHORISATION:
  - System may only be restarted with sign-off from: ___________________________
  - Restart requires: root cause identified + mitigation implemented + sign-off obtained

Part 4 — Documentation Requirements

4.1 Oversight Documentation Matrix

Document	Purpose	Owner	Frequency	Retention
Oversight Procedure Manual	Instructions for oversight personnel	Responsible AI Officer	Review annually	10 years
Override Log	Record of all human overrides	Human Overseer	Per override	10 years
Incident Reports	Record of serious incidents	Responsible AI Officer	Per incident	10 years
Training Records	Proof of oversight personnel competency	HR / Responsible AI Officer	Per training	Duration of role + 5 years
Competency Assessments	Baseline and periodic competency checks	Manager	Per person, annually	Duration of role + 5 years
Oversight Audit Reports	Periodic review of oversight effectiveness	Internal Audit	Quarterly/Annually	10 years
System Status Logs	Technical logs of system operation	System Administrator	Continuous	Defined in data retention policy
Post-Market Monitoring Reports	Aggregate performance and oversight findings	Responsible AI Officer	Quarterly/Annually	10 years

4.2 Minimum Logging Requirements

The following must be captured and stored for the required retention period:

For every AI system decision/output:

Unique decision identifier
Timestamp (UTC)
Input data reference (or hash)
Model version
Output value(s) and confidence score
Any flags or alerts triggered
Whether output was reviewed, overridden, or accepted by a human
Identity of human overseer who reviewed (where applicable)

For every override:

Override ID linked to original decision ID
Overseer identity
Reason for override (structured categories + free text)
Override decision
Timestamp

For every incident:

Part 5 — Monitoring Dashboards

5.1 Real-Time Oversight Dashboard Specification

The oversight dashboard must enable the human overseer to monitor the AI system effectively without requiring deep technical expertise. Use this specification to brief your development team:

Dashboard Panel 1: System Status

Widget	Data Source	Update Frequency	Alert Threshold
System health (Green/Amber/Red)	Health check API	Every 30 seconds	Any non-green
Output volume (last 1hr / 24hr / 7d)	Decision log	Every 1 minute	Volume spike > `___`% above baseline
Error rate (%)	Error log	Every 1 minute	Error rate > `___`%
Average confidence score	Decision log	Every 5 minutes	Average confidence < `____%`
Override rate (%)	Override log	Every 5 minutes	Override rate > `___`%

Dashboard Panel 2: Decision Stream (Human-on-the-Loop)

Widget	Data Source	Update Frequency
Live feed of most recent outputs	Decision log	Real-time
Flagged decisions awaiting review	Review queue	Real-time
Low-confidence decisions (< threshold)	Decision log	Real-time
Decisions affecting sensitive categories	Decision log	Real-time

Dashboard Panel 3: Performance Trends

Widget	Data Source	Time Window
Accuracy trend (rolling average)	Ground truth comparison	Rolling 30 days
Confidence score distribution	Decision log	Rolling 7 days
Prediction distribution (output categories)	Decision log	Rolling 7 days
Data drift indicator	Drift monitor	Rolling 7 days

Dashboard Panel 4: Override and Incident History

Widget	Data Source	Display
Override count and rate	Override log	Last 30 days
Top override reasons	Override log	Last 30 days
Open incidents	Incident tracker	Current
Incident trend	Incident tracker	Last 90 days

5.2 Alert Configuration

Configure alerts to notify oversight personnel of events requiring attention:

Alert Type	Trigger Condition	Notification Method	Recipients
Critical — System Down	System health = Red	SMS + Email	All oversight personnel
High — Confidence Threshold Breached	Avg. confidence < `____%` for > `___` min	Email + Dashboard	Human Overseer, Responsible AI Officer
High — Unusual Override Rate	Override rate > `___`% in `___` min	Email + Dashboard	Responsible AI Officer
Medium — Error Rate Spike	Error rate > `___`%	Email	System Admin, Human Overseer
Medium — Data Drift Detected	Drift index > `___`	Email	Responsible AI Officer, Technical Lead
Low — Performance Degradation	Accuracy < `___`% (rolling 7d)	Dashboard	Responsible AI Officer
Informational — Daily Summary	Every day at `__:__`	Email	All oversight personnel

Part 6 — Periodic Oversight Review

6.1 Weekly Oversight Review Checklist

To be completed by the Human Overseer or Responsible AI Officer each week:

Review override log — note patterns and trends
Review flagged decisions and their outcomes
Check performance KPIs against thresholds
Review any open incidents and their status
Confirm all oversight personnel completed required monitoring sessions
Note any anomalies or concerns for escalation

Weekly Review Record:

Week Ending	Reviewer	Override Count	Incidents	Performance Status	Action Items
`____-__-__`	`___________`	`___`	`___`	☐ Normal ☐ Concern	`___________`

6.2 Quarterly Oversight Effectiveness Review

Analyse override patterns — are overrides concentrated in specific scenario types?
Assess whether oversight procedures are being followed correctly (audit sample of override logs)
Review training records — are all oversight personnel current?
Review incident history — identify systemic issues
Test emergency stop procedure (planned drill): Date: ____-__-__
Assess whether oversight mode remains appropriate (human-in-the-loop vs. on-the-loop)
Review dashboard adequacy — are all required alerts and panels functioning?
Update oversight procedures if gaps identified
Report to senior management / Responsible AI Officer

6.3 Annual Oversight Governance Review

Full review of Article 14 compliance against latest regulatory guidance
Independent internal audit of oversight procedures and logs
Reassessment of overseer competencies
Review and update Oversight Procedure Manual
Update training materials
Benchmark against sector best practices
Update technical documentation (Annex IV Section 3)
Report to board / senior leadership with recommendations

Oversight Requirements by AI System Risk Profile

Use this table to calibrate the intensity of oversight to the risk profile of your system:

Risk Factor	Low-End Profile	High-End Profile	Oversight Intensity
Decision reversibility	Easily reversible (e.g., content recommendation)	Irreversible (e.g., loan denial, employment rejection)	Higher risk → Human-in-the-Loop
Affected population size	Small, defined group	Large, general population	Higher risk → More frequent oversight
Severity of potential harm	Minor inconvenience	Physical, financial, fundamental rights harm	Higher risk → Mandatory override capability
Speed of decision	Hours or days (time to intervene)	Real-time (seconds)	Faster → More robust auto-alert systems
Operator expertise	High domain expertise	Low AI/technical expertise	Lower expertise → Simpler interface + more training
System maturity	Proven, stable system	New or recently changed system	Less mature → More intensive oversight

Template	Purpose
`technical-documentation-annex-iv.md`	Annex IV Section 3 (Monitoring) and Section 14 (Instructions for Use)
`conformity-assessment.md`	Human oversight evidence for conformity assessment
`declaration-of-conformity.md`	Article 14 referenced in the declaration
`prohibited-practices-checklist.md`	Confirm oversight personnel awareness of prohibited practices

Template provided by VORLUX AI | vorluxai.com | This is guidance only, not legal advice.

Versión Española

Requisitos de supervisión humana para la implementación — Guía del artículo 14 de la Directiva UE sobre Inteligencia Artificial

Aviso: Esta es una guía solo, no asesoramiento legal. Consulte a un abogado calificado para sus obligaciones de cumplimiento específicas.

Plantilla proporcionada por VORLUX AI | vorluxai.com

Lo que exige el artículo 14

El artículo 14 de la Directiva UE sobre Inteligencia Artificial exige que los sistemas de IA de alto riesgo sean diseñados y desarrollados de tal manera que puedan ser efectivamente supervisados por personas naturales durante el período de uso. Esto no es solo una política requerida — debe estar integrado en la arquitectura del sistema y las proceduras operativas.

Las cuatro obligaciones centrales del artículo 14

Obligación	Artículo Ref	Qué significa
Supervisión significativa por diseño	14(1)	El sistema debe ser técnicamente capaz de ser sobrescrito, detenido o corregido
Interfaz adecuada para la supervisión	14(2)	Las herramientas y la información deben permitir al supervisor humano comprender y controlar realmente el sistema
Competencia del supervisor	14(3)	Las personas asignadas a supervisar el sistema deben tener el conocimiento y la autoridad necesarios para hacerlo de manera efectiva
Capacidad de sobrescritura y parada	14(4)	El supervisor debe poder intervenir en tiempo real y sobrescribir o interrumpir la operación del sistema

Parte 1 — Diseño de la mecanismo de supervisión

1.1 Requisitos a nivel de sistema

Antes de la implementación, confirme que se han implementado los siguientes en el sistema de IA:

Interpretabilidad y transparencia

Los resultados del sistema incluyen puntuaciones de confianza o estimaciones de incertidumbre donde sea técnicamente posible
El sistema proporciona explicaciones humanas interpretables para los resultados (apropiadas al nivel de riesgo y uso)
El sistema marca los casos en que está operando cerca o fuera de su límite de diseño
El sistema muestra las características de entrada más relevantes o factores contribuyentes a cada decisión

Interfaz de supervisión

Existe una interfaz de supervisión dedicada (panel, API o consola de operador)
La interfaz muestra el estado actual del sistema (en ejecución, pausado, degradado, error)
La interfaz muestra los datos de entrada, salida del modelo, confianza y factores clave de decisión
La interfaz proporciona acceso a registros de auditoría
La interfaz es accesible para el personal de supervisión sin conocimientos técnicos especializados

Capacidades de sobrescritura y control

Es posible la sobrescritura manual de decisiones individuales en tiempo real
La función de pausa / parada del sistema está disponible y accesible dentro de ____ segundos
Los resultados pueden marcarse para revisión humana antes de tener efecto (si el modo pre-decision es apropiado)
La revocación / reversión de decisiones de IA es posible durante un plazo definido después del resultado: ____ horas/días
El fallback a un proceso manual está documentado y probado

Controles de arquitectura técnica

Control	Implementación	Fecha de prueba	Resultado de la prueba
Botón de emergencia / punto final API	`___________`	`____-__-__`	☐ Aprobado ☐ Rechazado
Rastro de auditoría de decisiones (tamper-evident)	`___________`	`____-__-__`	☐ Aprobado ☐ Rechazado
Monitoreo en tiempo real de resultados	`___________`	`____-__-__`	☐ Aprobado ☐ Rechazado
Registro de supervisión humana	`___________`	`____-__-__`	☐ Aprobado ☐ Rechazado
Capacidad de retroceso	`___________`	`____-__-__`	☐ Aprobado ☐ Rechazado

1.2 Matriz de nivel de supervisión

Defina cuando la supervisión humana es activa y qué nivel se requiere:

Modo operativo	Descripción	Nivel de supervisión requerido	Disparador
Human-in-the-Loop	Cada decisión revisada antes de tener efecto	Revisión completa de cada resultado	Decisiones de alto riesgo; contextos de baja volumetría
Human-on-the-Loop	La IA actúa; el humano monitorea y puede sobrescribir	Muestreo + alertas de anomalías	Volumen medio; decisiones reversibles
Human-over-the-Loop	La IA opera de manera autónoma; auditoría humana periódica	Auditoría de muestra + panel de indicadores clave (KPI)	Volumen alto; decisiones de menor riesgo; reversibles

Parte 2 — Formación y competencia del supervisor

2.1 Requisitos de competencia (Art. 14(3))

Cada persona asignada como supervisor de un sistema de IA debe cumplir:

Competencia	Evidencia requerida	Verificación
Comprensión del propósito y limitaciones del sistema	Certificado de formación	☐ Completado
Capacidad para interpretar resultados y puntuaciones de confianza	Evaluación práctica	☐ Aprobado
Conocimiento del dominio relevante al uso del sistema	Cualificación profesional o experiencia documentada	☐ Verificado
Conocimiento de sesgos potenciales y modos de fallo	Módulo de formación específico	☐ Completado
Capacidad para usar la interfaz de sobrescritura	Ejercicio práctico supervisado	☐ Demostrado
Autoridad para detener el sistema si es necesario	Autorización formal por escrito	☐ Firmado

2.2 Plan de formación

Formación inicial antes de la primera supervisión (mínimo ___ horas)
Formación de actualización cada ___ meses
Simulacro de intervención/sobrescritura cada ___ meses
Registro de formación archivado como evidencia de cumplimiento

Parte 3 — Protocolo de intervención y sobrescritura

3.1 Procedimiento de sobrescritura en 6 pasos

Paso 1: IDENTIFICAR — Anotar el resultado del sistema y la razón de preocupación
Paso 2: EVALUAR — Revisar evidencia (entradas, confianza, explicación)
Paso 3: DECIDIR — Sobrescribir, pausar, escalar o aceptar
Paso 4: ACTUAR — Usar interfaz de sobrescritura, registrar decisión
Paso 5: DOCUMENTAR — Completar el registro de sobrescritura
Paso 6: SEGUIMIENTO — Verificar que el resultado fue aplicado correctamente

3.2 Registro de sobrescritura

Campo	Valor
ID de sobrescritura	`OVR-____-____-____`
Fecha y hora	`____-__-__` `__:__:__`
Resultado original del sistema	`___________________________`
Confianza del sistema	`____%`
Razón de la sobrescritura	`___________________________`
Decisión humana	`___________________________`
¿Escalado?	☐ Sí → ID: `___` ☐ No
¿Supervisor notificado?	☐ Sí ☐ No

Parte 4 — Mejora continua y auditoría

4.1 Revisión periódica

Revisión mensual de métricas de supervisión
Análisis trimestral de patrones de sobrescritura
Informe anual de cumplimiento para dirección
Actualización de umbrales basada en rendimiento real

4.2 Métricas de supervisión

Métrica	Objetivo	Frecuencia
Tasa de sobrescritura	< `__`% de decisiones	Mensual
Tiempo medio de intervención	< `__` minutos	Mensual
Cobertura de formación	100% supervisores activos	Trimestral
Simulacros completados	≥ 1 por trimestre	Trimestral
Incidentes escalados	Seguimiento 100%	Continuo

¿Necesita ayuda implementando supervisión humana para sus sistemas de IA? Contacte con VORLUX AI para una evaluación personalizada.