Uso responsable de IA

Cómo diseñamos y usamos la inteligencia artificial en Domora.

En esta página · ver apartados

Domo se gobernará como un sistema socio-técnico: modelo, prompts, retrieval, herramientas, datos, proveedores y supervisión. Cambiar un modelo no es un cambio aislado si altera comportamiento, localización de datos, términos o capacidad de acción.

1. Ámbito y roles AI Act

Para cada sistema debe documentarse si Domora actúa como proveedor, responsable del despliegue (deployer), importador/distribuidor u otro rol conforme al AI Act. El rol depende de cómo se desarrolla, comercializa y utiliza el sistema; no se declara una única etiqueta para toda la empresa. Cuando Domora integra un modelo de propósito general de un tercero dentro de Domo, conserva obligaciones propias respecto del sistema que ofrece/implementa, además de las del proveedor upstream que resulten aplicables.

3. Transparencia al interactuar con IA

4. Prácticas no permitidas y red flags

  • No diseñar manipulación subliminal/deceptiva ni explotar vulnerabilidades de personas de forma contraria al AI Act.
  • No inferir categorías sensibles o emociones salvo análisis jurídico específico; evitar especialmente cualquier “emotion recognition” innecesario.
  • No crear social scoring ni utilizar datos de comunidades para evaluar confiabilidad general de personas.
  • No identificar biométricamente por voz sin un caso jurídico/técnico específico y revisión reforzada.
  • No permitir que un LLM decida por sí solo permisos, tenant access o autorización de acciones.
  • No ocultar que una voz sintética es IA cuando la transparencia sea exigible.

5. Human oversight y matriz de autonomía

Acción de DomoAutonomía máxima recomendadaControl
Recoger datos y crear borrador de incidenciaautomática con confirmación del usuario cuando haya ambigüedadvalidación esquema + tenant/property verification.
Detectar posible duplicadorecomendar, no cerrar automáticamente si existe riesgomostrar coincidencia/confidence; override.
Clasificar/priorizarsugerir; reglas determinísticas para urgencia críticahuman override + logging.
Enviar email informativo de bajo riesgoautomática solo con template/recipients autorizados y reglaspreview/log/rate limits según caso.
Contactar proveedor/crear ordenaprobación humana por defecto hasta validar clases de bajo riesgoallowlist + confirmation + audit.
Modificar datos financierossin autonomía por defectopermiso reforzado + confirmación humana.
Iniciar/autorizar pagoprohibido sin diseño regulatorio/contractual específicohuman authorization + payment provider controls.
Emitir/cerrar acta o firmasin autonomíaórganos/personas competentes revisan y firman.
Borrar datos/usuariossin autonomía salvo workflows reversibles y autorizadosstep-up auth/approval.

7. Datos, prompts y modelos

  • Minimizar contexto; retrieval basado en permisos server-side.
  • No enviar conjuntos completos si bastan fragmentos/campos.
  • Separar system prompts de contenido no confiable.
  • Versionar prompts/config/model y poder reproducir qué versión generó un output.
  • No almacenar chain-of-thought interno; guardar únicamente logs operativos necesarios (input/output/tool events/decisions) de forma proporcional.
  • No usar Customer Data para entrenamiento general por defecto; cualquier excepción requiere revisión/contrato/transparencia y controles.
  • Evaluar model/vendor changes como change de riesgo, no solo optimización técnica.

8. Contenido sintético

Cuando Domora genere contenido sintético sujeto a obligaciones específicas del artículo 50 AI Act, deberá evaluar los requisitos de marcado/transparencia aplicables al tipo de output. Para borradores internos de texto, el foco práctico es evitar que el usuario confunda un borrador no revisado con un documento definitivo. Para audio sintético de Domo, la interacción debe quedar identificada como IA.

Marco normativo y fuentes de referencia

Las referencias se incluyen para trazabilidad jurídica. Deben revisarse de nuevo cuando se modifique el producto, el flujo de datos o la normativa aplicable.