Política de Uso de IA
Uso responsable de la inteligencia artificial. Clasificación EU AI Act, transparencia y human-in-the-loop.
- SHARA NO toma decisiones con efectos jurídicos sin aprobación humana
- Categorización EU AI Act: NO Anexo III (alto riesgo) · sí GPAI art. 50 cuando aplica
- Suite anti-prompt-injection red-team-v2: 54 ataques, ≥95% neutralizado
- Kill-switches automáticos · modo low-spending fuera de horario · log agent_runs
- No entrenamos modelos con tus datos · opt-out activado en proveedores LLM
En SHARA usamos modelos de lenguaje grandes (LLM) y otras técnicas de inteligencia artificial para asistir a equipos administrativos en sus tareas diarias. Esta política describe nuestros principios, las medidas de transparencia y seguridad aplicables al sistema, y cómo cumplimos con el RGPD y el Reglamento (UE) 2024/1689 de Inteligencia Artificial ("EU AI Act"). El documento está dirigido tanto al Cliente como a los interesados cuyos datos se tratan en el Servicio.
1. Compromisos básicos
- Asistencia, no sustitución: SHARA propone, redacta y agiliza, pero las decisiones que producen efectos jurídicos o económicos significativos requieren aprobación humana a través de la approval queue.
- Transparencia operativa: cada acción de un agente queda registrada en el log de auditoría y es consultable por el Cliente con detalle por agent_run.
- Soberanía del dato: los datos del Cliente no se utilizan para entrenar modelos propios ni de terceros.
- Mitigación activa de riesgos: kill-switches, modo low-spending, red-teaming continuo y aprobación humana en acciones críticas.
- Reversibilidad: el Cliente puede desactivar agentes, conectores y automatizaciones en cualquier momento desde el panel de administración.
2. Mapeo EU AI Act
| Clasificación | Aplicación a SHARA | Obligaciones aplicables |
|---|---|---|
| Anexo III, alto riesgo | SHARA, en su uso por defecto, no encaja: es asistente administrativo, no decisor en empleo, crédito, justicia o servicios esenciales. | Si el Cliente pretende usarlo en un caso del Anexo III, debe contactarnos previamente: ese uso requiere DPIA, FRIA y controles adicionales contractuales y técnicos. |
| Art. 5, prácticas prohibidas | SHARA no realiza ninguna: no manipula subliminalmente, no explota vulnerabilidades, no hace social scoring, no realiza identificación biométrica masiva. | Política de uso aceptable que prohíbe expresamente al Cliente cualquier uso del art. 5. |
| Art. 50, transparencia GPAI | Sí aplica: SHARA es un sistema de IA de propósito general en interacción con personas. | Informamos a los usuarios de que están interactuando con un sistema de IA y, cuando aplique, marcamos el contenido como generado o modificado por IA. |
| Art. 52, deepfakes | SHARA no genera deepfakes audiovisuales por defecto; sus salidas son textuales o estructuradas. | Prohibición expresa al Cliente de generar deepfakes con SHARA salvo casos de marketing identificados claramente como sintéticos. |
| Capítulo V, modelos GPAI | Aplica indirectamente vía los proveedores LLM (terceros bajo NDA), que asumen las obligaciones del capítulo. | Exigimos a los proveedores documentación técnica y compromisos de transparencia razonables. |
3. Decisiones automatizadas y human-in-the-loop
Conforme al artículo 22 del RGPD, SHARA está diseñado para no tomar decisiones exclusivamente automatizadas con efectos jurídicos significativos sobre el interesado. El mecanismo de control es la approval queue: las acciones críticas se encolan y requieren aprobación por un humano autorizado del Cliente antes de ejecutarse.
4.1 Acciones que requieren aprobación obligatoria
| Tipo de acción | Por qué requiere humano |
|---|---|
| Envío de email externo en nombre del Cliente | Compromiso reputacional y posible riesgo legal si el contenido es incorrecto. |
| Ejecución de pago u orden bancaria | Efecto económico inmediato e irreversible. |
| Contratación, despido o modificación contractual de personal | Efectos jurídicos y derechos fundamentales (art. 22 RGPD). |
| Modificación contractual con clientes o proveedores | Compromisos legales y económicos. |
| Decisión de RRHH (selección, evaluación, promoción) | Anexo III EU AI Act y arts. 22 + 21 RGPD. |
| Comunicación pública en nombre del Cliente (RRSS, prensa) | Riesgo reputacional. Trazabilidad firmada por humano. |
| Cambio en políticas de la cuenta (permisos, configuración crítica) | Impacto sistémico interno. |
El Cliente puede ampliar este listado y elevar el umbral por agente, tipo de acción y rango económico desde el panel de administración.
4. Bias y discriminación
Los LLM pueden reproducir sesgos presentes en sus datos de entrenamiento. Aplicamos medidas para detectarlos y mitigarlos:
- Casos de bias detection en la suite de red-team v2 (lenguaje, género, origen, edad, capacidad).
- Plantillas de prompt revisadas para reducir formulaciones discriminatorias en agentes que afectan a personas (Maslow / RRHH, Carlzon / atención).
- Evaluación periódica con dataset de control y publicación de métricas internas a clientes Max/Plan Local que lo soliciten.
- Opt-out de modelos por cliente: los planes Max y Plan Local pueden excluir alias concretos si su evaluación interna detecta sesgos no aceptables.
- Recomendación explícita de no utilizar SHARA, sin DPIA específica, para decisiones automatizadas en acceso al empleo, crédito o servicios esenciales.
5. Anti-prompt-injection y robustez
El input externo (correos, documentos, contenido web) es potencialmente hostil. Aplicamos:
- Suite de red-team con cobertura de los OWASP LLM Top 10 y casos específicos del producto: direct prompt injection, indirect injection vía documentos, data exfiltration, sensitive information disclosure, insecure plugin design, etc.
- Mínimo de 50 ataques adversariales en el conjunto vigente (54 en el momento de publicación de esta política); el gate de release exige ≥95% de ataques neutralizados.
- Refuerzo en el prompt de sistema para tratar el input externo como contenido a procesar, no como instrucciones a ejecutar.
- Redactor post-respuesta que filtra cualquier mención del modelo real, del prompt de sistema, de IDENTITY.md o de información interna.
- Aislamiento de roles internos: los agentes no comparten estado más allá de lo estrictamente necesario para el caso de uso.
6. Kill-switches y modo low-spending
- Por gasto: el sistema corta o degrada automáticamente cuando se rebasa 5 €/run, 50 €/hora o 400 €/día.
- Por tasa de error: bucles infinitos detectables se cortan automáticamente.
- Modo low-spending: fuera del horario laboral configurado (tenants.business_hours), Amadeus degrada modelos automáticamente (Symphony→Sonata, Sonata→Prelude, Prelude limita max_tokens=500).
- Manual: el Cliente puede activar un kill-switch global ("pausar todos los agentes") en cualquier momento desde el panel.
7. Auditabilidad
La aplicación expone al Cliente un panel de auditoría con el detalle por agent_run: agente, modelo alias, prompt-hash, tokens consumidos, latencia, modo (normal/low-spending), resultado y aprobaciones humanas asociadas. Estos registros se conservan según la política descrita en /privacidad y permiten reconstruir el historial de cada decisión sin necesidad de revelar el modelo real.
8. Datos de entrenamiento
- SHARA no entrena modelos con datos del Cliente. El producto consume modelos pre-entrenados de proveedores y los ejecuta sobre los datos del Cliente sin retroalimentación.
- Los proveedores de modelos contratados por SHARA están sujetos a opt-out de uso de prompts y respuestas para entrenamiento. Mantenemos esa cláusula activa en todo momento y la verificamos anualmente.
- Las mejoras del producto (fine-tuning interno, evaluaciones) se realizan con datos sintéticos o anonimizados que no permiten reidentificación.
- Cláusula de auditoría del Cliente: en planes Max y Plan Local el Cliente puede solicitar evidencia razonable del cumplimiento de estos compromisos (declaraciones del proveedor, configuración de la cuenta, registros agregados) bajo NDA.
9. Limitaciones conocidas
Por transparencia, declaramos las limitaciones inherentes al estado del arte:
- Alucinaciones: los LLM pueden generar contenido plausible pero incorrecto. La approval queue es la salvaguarda principal.
- Dependencia de la calidad de los datos: el output depende de la calidad y actualización de las fuentes del Cliente.
- Contexto limitado: existe una ventana de contexto máxima por modelo; tareas que excedan esa ventana se trocean y pueden perder coherencia entre fragmentos.
- Posibles desactualizaciones: los modelos pueden no conocer hechos recientes; el Cliente conecta fuentes para mitigarlo, pero la capa de razonamiento puede arrastrar conocimiento obsoleto.
- Variabilidad: dos ejecuciones idénticas pueden producir outputs distintos; usamos baja temperatura por defecto y prompts deterministas en agentes críticos.
- Idioma: el rendimiento es óptimo en español e inglés. Otros idiomas pueden tener peor calidad y se desaconseja su uso para outputs críticos sin revisión humana.
10. Control del cliente sobre los agentes
El Cliente puede en cualquier momento desactivar agentes específicos, limitar su acceso a determinados conectores, restringir el envío automático y elevar el umbral de approval queue. Estos cambios se aplican en tiempo real desde el panel de administración. Cada cambio queda registrado en audit_logs con identidad del administrador y timestamp.
11. Reportar problemas de IA
Si detectas un comportamiento del sistema que consideras peligroso, sesgado, discriminatorio o que filtra información que no debería, repórtalo a soporte@aiginer.com con la mayor cantidad de detalle posible:
- run_id (visible en el panel de auditoría).
- Captura o transcripción del comportamiento observado.
- Resultado esperado vs. resultado obtenido.
- Impacto observado (real o potencial) y datos afectados.
Tratamos las incidencias de seguridad e IA bajo el runbook documentado en el Threat Model. Triamos en menos de 5 días hábiles y, cuando proceda, notificamos a la autoridad correspondiente.
12. Revisión de la política
Esta política se revisa al menos anualmente y siempre que se incorpore un nuevo proveedor de modelo, se modifique sustancialmente la arquitectura del sistema o cambie la normativa aplicable (RGPD, EU AI Act, leyes nacionales). El historial de versiones figura al pie del documento.