Clasificacion de sistemas de AI: Guia practica para equipos SaaS

La clasificacion de sistemas de AI es el paso operativo que decide que reglas, controles, evidencia y ruta de revision aplican a una funcion de AI, un workflow interno o una herramienta de tercero. Para un equipo SaaS, el resultado util no es una nota que dice bajo riesgo o alto riesgo. El resultado util es una decision documentada que producto, engineering, legal, seguridad y compliance puedan usar al construir, comprar, lanzar, monitorear y explicar el sistema.

Segun el EU AI Act, la clasificacion importa porque distintas categorias de sistemas de AI pueden activar distintas obligaciones. En sistemas de alto riesgo pueden ser relevantes gestion de riesgos, gobernanza de datos, documentacion tecnica, logging, transparencia, supervision humana, precision, robustez, ciberseguridad y monitoreo posterior. Por eso la clasificacion debe ser un workflow repetible, no una etiqueta unica.

Por que importa en la practica

Sin clasificacion, el equipo no sabe con seguridad que controles aplican, quien aprueba el lanzamiento, que evidencia se conserva o como responder a clientes. En SaaS esto es especialmente importante porque la AI aparece por incrementos: resumenes en soporte, copilotos internos, scoring de vendors o modelos incorporados en workflows ya existentes.

Tambien afecta la preparacion comercial. Los compradores enterprise preguntan donde se usa AI, que datos toca, si los outputs influyen en usuarios y que controles evitan automatizacion inadecuada. Un sistema clasificado permite responder desde evidencia, no desde memoria.

Que deben clasificar los equipos SaaS

Empiece con un inventario amplio. Incluya funciones de producto, workflows internos, servicios de vendors, integraciones de modelos, automatizaciones y procesos de decision support que usen AI o machine learning. Incluya tambien funcionalidades menos visibles como clasificacion, recomendaciones, priorizacion, extraccion, scoring, prediccion, moderacion, personalizacion o resumen.

Para cada sistema, registre que hace, si es interno o de un vendor, que datos procesa, quien se ve afectado, si el output informa, recomienda o decide, si una persona lo revisa, donde se usa y si toca contextos sensibles, regulados o de alto impacto.

Workflow practico

Defina disparadores de revision. Debe haber clasificacion cuando se introduce una nueva funcion de AI, cambia su finalidad, se conecta una nueva fuente de datos, se incorpora un vendor AI, cambia la supervision humana, se entra en un nuevo mercado o una pregunta de cliente muestra que la decision anterior no basta.

Luego recopile los hechos minimos con un intake corto: finalidad, datos, personas afectadas, workflow, revision humana, vendor o modelo, geografia y owner de producto. Despues haga una clasificacion inicial para decidir si el caso queda fuera de una ruta regulatoria profunda, si es una ayuda de productividad ordinaria o si necesita evaluacion adicional por dominios sensibles, usuarios afectados o posible alto riesgo.

Documente la razon. Un label solo no es evidencia fuerte. Una buena decision explica los hechos, quien la reviso, que fuentes se consultaron y cuando debe revisarse. Conecte despues la clasificacion con tareas: risk assessment, data governance, vendor review, supervision humana, logging, testing, avisos a usuarios, documentacion para clientes y monitoring.

Cuando revisar alto riesgo

No toda funcion AI en SaaS sera de alto riesgo. Pero el equipo tampoco debe descartar la revision porque el producto sea solo software. El Article 6 del AI Act establece rutas de clasificacion de alto riesgo, incluyendo productos cubiertos por legislacion armonizada de la UE y sistemas usados en areas de Annex III. La guia de la Comision ayuda a interpretar esas reglas.

Debe prestarse especial atencion a empleo, gestion de trabajadores, acceso a servicios esenciales, educacion, credito, law enforcement, migracion, justicia, procesos democraticos, usos biometricos o componentes de seguridad. Un asistente interno de redaccion es distinto de una herramienta que puntua candidatos, ordena usuarios o influye en acceso a un servicio importante.

Evidencia a conservar

Conserve el inventario AI, el intake, la decision de clasificacion, la razon, owner y aprobador, fuentes consultadas, risk assessment, vendor review, controles activados y fecha de proxima revision. Esa evidencia reduce repeticion, facilita audits y ayuda a responder reviews de clientes.

Errores comunes

El primer error es clasificar demasiado tarde. Si el feature ya se lanzo, puede faltar documentacion, supervision, testing o explicacion para clientes. El segundo es tratar la AI de vendors como problema ajeno. La documentacion del vendor importa, pero el SaaS team debe entender su propio uso, datos, impacto y controles.

Tambien es comun usar labels demasiado amplios, separar clasificacion de change management y mantener el proceso en una hoja aislada sin conexion con security review, privacy review, vendor risk, aprobacion de lanzamiento, incident response y customer trust.

FAQ

Cual es el proposito practico?

Decidir que ruta de governance aplica al caso de AI y crear evidencia para esa decision.

Cuando aplica a SaaS?

Cuando el equipo construye, compra, integra, vende o depende materialmente de un sistema AI en producto u operaciones.

Que documentar primero?

Finalidad, datos, personas afectadas, impacto de decision, revision humana, vendor, geografia, owner, clasificacion, razon y controles activados.

Fuentes

• Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence.
• European Commission guidance on high-risk AI systems.
• NIST Artificial Intelligence Risk Management Framework.