Los controles deben corresponder al sistema.

Diseñamos para el perímetro que la carga realmente necesita. La disponibilidad de un modelo concreto depende de la arquitectura del proyecto y de las restricciones del proveedor.

• Cloud pública o gestionada cuando la carga de trabajo lo permite.
• Cloud dedicada / privada o VPC del cliente cuando aislamiento y residencia lo requieren.
• Arquitecturas híbridas cuando determinados datos o sistemas deben permanecer en infraestructura del cliente.
• Componentes on-premise o self-hosted cuando el caso operativo y regulatorio justifica la complejidad adicional.

Los controles de datos se documentan por sistema en lugar de insinuarse mediante una promesa genérica en la web.

• Residencia, retención y borrado de datos se definen por proyecto antes de producción.
• Los requisitos de cifrado, gestión de claves y aislamiento de red se seleccionan según el entorno de despliegue y las políticas del cliente.
• El tratamiento de datos por los proveedores de modelos se revisa contractual y técnicamente para los proveedores realmente utilizados.
• Los datos sensibles se minimizan por diseño; el sistema no debería recopilar o conservar información solo porque un modelo pueda consumirla.

Los agentes necesitan identidades explícitas y autoridad delegada, no solo credenciales de API.

• Pueden integrarse patrones de identidad corporativa y SSO cuando el entorno del cliente los soporta.
• Los permisos del agente se limitan al conjunto mínimo útil de recursos y acciones.
• Leer, proponer, aprobar y ejecutar se tratan como capacidades distintas.
• Las acciones privilegiadas o con consecuencias relevantes pueden requerir aprobación humana explícita.

La supervisión humana forma parte del diseño de ejecución; no es un aviso colocado después del output del modelo.

• La autonomía se decide por flujo de trabajo, no por modelo.
• Los checkpoints humanos se sitúan en pasos con consecuencias, ambigüedad o sensibilidad de política.
• Los sistemas incluyen comportamiento definido para detener, escalar y recuperar; no se presupone que el modelo completará siempre la tarea correctamente.
• Los requisitos de reversión y override se diseñan junto al sistema de registro subyacente.

Qué se registra depende de las consecuencias, la regulación y los sistemas afectados.

• El modelo de auditoría se define antes del despliegue: qué debe registrarse, quién puede inspeccionarlo y durante cuánto tiempo se conserva.
• Las trazas relevantes pueden incluir llamadas a modelos, uso de herramientas, aprobaciones, decisiones de política y escrituras en sistemas de registro.
• Exportación e integración con SIEM se diseñan según los requisitos operativos del cliente cuando son necesarias.
• La auditabilidad forma parte de la arquitectura; retención y mecanismos de evidencia de manipulación dependen del despliegue concreto.

Evitamos dependencia de proveedor innecesario, pero no fingimos que todos los proveedores son intercambiables en cualquier workload.

• La selección de modelo considera calidad de tarea, latencia, coste, privacidad, seguridad y restricciones de despliegue.
• Enrutado y contingencia se introducen cuando el caso de negocio justifica resiliencia multi-modelo o control de costes.
• Cambios de proveedor y deprecaciones de modelos se tratan como riesgos de lifecycle.
• Modelos open-weight o self-hosted se consideran cuando mejoran materialmente control, residencia o economía.

La readiness de producción se mide contra el trabajo que debe realizar el sistema.

• Los criterios de aceptación se definen contra el resultado del flujo de trabajo, no contra un benchmark genérico del modelo.
• Las evaluaciones preproducción cubren casos representativos, modos de fallo y límites de política.
• La evaluación en producción puede muestrear trazas reales con la privacidad y gobernanza adecuadas al despliegue.
• Métricas y cadencia de revisión se acuerdan por proyecto; no afirmamos una tasa universal de precisión o alucinación.

La telemetría operativa se diseña alrededor de fallo, coste y consecuencia.

• Métricas, logs y trazas se eligen alrededor de los riesgos operativos del flujo de trabajo.
• Pueden utilizarse patrones compatibles con OpenTelemetry cuando encajan con el stack de observabilidad del cliente.
• Umbrales de latencia, disponibilidad, errores y coste se definen para el sistema que se opera.
• Alertas y dashboards se integran con las herramientas del cliente cuando lo requiere el modelo operativo.

Los compromisos de soporte pertenecen al contrato y al runbook del proyecto, no al copy genérico de marketing.

• Responsabilidad de incidentes, niveles de severidad y rutas de escalado se acuerdan antes del handover a producción.
• Horarios de soporte, objetivos de respuesta y posibles SLA son decisiones contractuales, no garantías universales de la web.
• Los incidentes materiales deben alimentar evals, controles, runbooks y decisiones de arquitectura.
• La comunicación al cliente y la revisión post-incidente se definen para el modelo de soporte realmente contratado.

Ingenierizamos sistemas teniendo en cuenta las obligaciones de gobernanza aplicables y trabajando junto a las funciones legales, de riesgo, seguridad y auditoría del cliente.

• RGPD / GDPR — requisitos de privacy by design y gobierno del dato cuando resulten aplicables.
• EU AI Act — clasificación de riesgo, transparencia, documentación técnica y supervisión humana cuando corresponda.
• NIS2 — consideraciones de seguridad y supply chain para organizaciones dentro de alcance.
• ISO/IEC 42001 e ISO/IEC 23894 — marcos útiles de gestión y riesgo para programas de IA.
• NIST AI RMF — referencia práctica para gobernar, mapear, medir y gestionar riesgos de IA.

Lexdatum es una consultora de ingeniería. Referenciar una norma o regulación significa que podemos diseñar alrededor de sus requisitos cuando corresponda; no significa que Lexdatum o un sistema cliente esté certificado, auditado o sea legalmente compliant por defecto.

No existe una lista universal de subencargados para clientes porque los despliegues son específicos de cada proyecto.

• Esta web pública está alojada actualmente en Vercel.
• Proveedores de modelos, cloud, email, observabilidad e integración se introducen solo cuando la arquitectura seleccionada los requiere.
• Antes de que un proveedor trate datos del cliente, su rol, flujo de datos, región, retención y posición contractual deberían quedar documentados para ese proyecto.
• Se proporciona un registro vigente de proveedores / subencargados cuando sea relevante para procurement o revisión de protección de datos.