Una historia de alguien que se mudó para usar legalmente un LLM en una pyme de 12 hombres y, si es posible, también para certificar de acuerdo con ISO 41001. Esto es, por así decirlo, la colección de ideas del plan del proyecto y la lluvia de ideas de la estructura de nivel de entrada.
Nota sobre el uso de este documento
Este plan de proyecto se creó como una base de trabajo estructurada y clasifica los pasos técnicos, organizativos y legales para la introducción de Open WebUI + Ollama como una solución de IA en las instalaciones, así como el camino hacia una posible certificación ISO / IEC 42001.
REDDIT IANAL (No soy abogado) Descargo de responsabilidad: Las evaluaciones jurídicas sobre el RGPD, NIS2/BSIG-neu y la Ley de IA de la UE se basan en el estatuto jurídico público de agosto de 2026 y no sustituyen al asesoramiento jurídico en casos individuales. En el caso de las declaraciones jurídicamente vinculantes (en particular, sobre el nombramiento de un delegado de protección de datos, la necesidad de una evaluación de impacto en materia de protección de datos y la aplicabilidad de la SRI 2), se recomienda consultar a un bufete de abogados especializado en legislación en materia de protección de datos y seguridad informática o a un consultor externo debidamente cualificado.
contenidos
1. Resumen ejecutivo
2. Situación inicial y objetivos
3. Sinopsis del marco jurídico
4. Análisis detallado: Protección de datos (GDPR / BDSG)
5. Análisis detallado: NIS2 / BSIG-nuevo
6. Análisis detallado: Ley de IA de la UE
7. ISO/IEC 42001 – Vía hacia la certificación
8. Arquitectura técnica e implementación
9. Organización y roles del proyecto
Plan de fase e hitos
11. Gestión de riesgos
12. Planificación de costos y recursos
13. Criterios de éxito
14. Próximos pasos (primeros 30 días)
15. Anexo 18
1. Resumen ejecutivo
La compañía planea introducir Open WebUI como una interfaz autoalojada basada en navegador para modelos de lenguaje de IA locales (basada en: Ollama) para proporcionar a los 12 empleados un asistente de IA compatible con la protección de datos para el trabajo de texto, la búsqueda de conocimientos en documentación técnica (RAG) y otros casos de uso (completamente en su propia infraestructura) sin transferir datos de la empresa o del cliente a proveedores externos de nube.
El presente plan de proyecto tiene tres objetivos paralelos:
- Introducción técnica: Pila de IA in situ robusta, de alto rendimiento y operada de forma segura (Open WebUI, Ollama, base de datos de conocimientos RAG, control de acceso).
- Cumplimiento legal desde el principio: Consideración del RGPD/BDSG, la Ley de IA de la UE y una evaluación bien fundada y específica para cada empresa de la aplicabilidad de la NIS2 (BSIG-nueva).
- Capacidad para certificar: Desarrollo de un sistema de gestión de IA (AIMS) que cumpla con los requisitos de ISO/IEC 42001 y pueda certificarse externamente.
Principales conclusiones por adelantado:
- La operación en las instalaciones es la principal ventaja en virtud de la ley de protección de datos: Mientras no haya flujos de datos a API de modelos externos, plugins de búsqueda web o servicios en la nube, no se producirá ningún procesamiento de pedidos de conformidad con el artículo 28 del RGPD con respecto a un proveedor de IA. Esta ventaja debe garantizarse técnica y organizativamente (véanse los capítulos 4 y 8).
- Tal como están las cosas hoy en día, NIS2 no debería ser directamente obligatorio: Con doce empleados, se espera que la empresa se sitúe por debajo de los umbrales de «entidades importantes» o «particularmente importantes». No obstante, se recomiendan orientaciones voluntarias sobre las medidas de referencia NIS2, entre otras cosas debido a los posibles requisitos de la cadena de suministro de los clientes más grandes (véase el capítulo 5).
- La Ley de IA de la UE ya afecta a la empresa en partes: en particular, la obligación de impartir capacidades de IA (artículo 4 del Reglamento de IA), que es aplicable desde febrero de 2025, con independencia del tamaño de la empresa. Las obligaciones de alto riesgo no son pertinentes para el caso de uso previsto (véase el capítulo 6).
- ISO/IEC 42001 es voluntaria pero estratégica: Como prueba para los clientes de la cadena de suministro de tecnología de medición y fabricación y como base estructural para la gobernanza de la IA legalmente conforme (véase el capítulo 7).
El período total previsto hasta la madurez de la certificación es de aproximadamente 10-12 meses, dividido en ocho fases del proyecto (Capítulo 10). En el capítulo 12 figura una primera estimación aproximada de los costes.
2. Situación inicial y objetivos
2.1 Situación inicial
La empresa es una PYME con 12 empleados en el campo de la tecnología de medición industrial. Las categorías de datos típicas en dicho establecimiento incluyen dibujos técnicos y datos de diseño, registros de medición y datos de calibración, documentación del cliente (en parte bajo NDA), documentación interna de procesos y calidad (por ejemplo, en el contexto de ISO 9001) y datos personales de empleados, clientes y proveedores. Estos datos se clasifican regularmente como secretos comerciales y comerciales en el sentido de la Ley de Secretos Comerciales (GeschGehG) y a menudo están sujetos a obligaciones contractuales adicionales de confidencialidad con respecto a los clientes de la industria manufacturera.
Las herramientas de chat de IA basadas en la nube (por ejemplo, ChatGPT, Copilot, Gemini en la configuración estándar) significarían una transferencia a proveedores no europeos o externos en esta situación de datos, lo que es arriesgado tanto en virtud de la legislación de protección de datos como contractualmente en un entorno B2B sensible con obligaciones de confidencialidad. Una solución autoalojada y operada en las instalaciones, como Open WebUI en combinación con Ollama, básicamente evita esta salida de datos, ya que el modelo y los datos permanecen completamente en su propia infraestructura.
2.2 Objetivos del proyecto
- Suministro de un asistente de IA interno que cumpla con el RGPD para los 12 empleados (borradores de texto, resúmenes, investigación en documentación interna, soporte de perspectiva para textos de ofertas e informes).
- Desarrollo de una base de conocimientos soportada por RAG basada en documentación técnica interna, manuales y estándares, sin que este contenido salga de la empresa.
- Establecimiento de una base operativa conforme con la legislación (protección de datos, política de uso de la IA, concepto de función y derechos).
- Establecer un sistema de gestión de IA (AIMS) y obtener la certificación de acuerdo con ISO / IEC 42001 dentro de aproximadamente 12 meses después del inicio del proyecto.
- Creación de un punto de referencia para las consultas y licitaciones de los clientes, que requieren cada vez más pruebas del uso responsable de la IA y la seguridad de la información.
2.3 Delimitación (no objetivos)
- No utilizar la IA para la toma de decisiones automatizada con respecto a los clientes o solicitantes (sin elaboración de perfiles, sin decisiones individuales automatizadas en el sentido del artículo 22 del RGPD).
- No integrar el componente de IA en los productos de medición física ni en el control de la producción como parte de este proyecto (esto requeriría la reclasificación como sistema de IA de alto riesgo con arreglo al anexo I del Reglamento de IA de la UE, véase el capítulo 6.3).
- Ningún uso productivo de funciones adicionales de IA basadas en la nube (búsqueda web externa, generación de imágenes externas, API de lenguaje externo) en la configuración básica, ya que serían contrarias al enfoque local (véase el capítulo 8.6).
- No hay decisiones de personal o evaluaciones de rendimiento basadas en evaluaciones de IA de los datos de los empleados.
3. Visión general del marco jurídico
La siguiente tabla resume qué regulaciones son relevantes para el proyecto, si son vinculantes para una empresa de este tamaño y qué sigue específicamente para el proyecto. El análisis detallado se lleva a cabo en los capítulos 4 a 7.
| Normas y reglamentos | encuadernación | Obligación básica | Relacionado con el proyecto |
| GDPR / BDSG | Encuadernación (siempre) | Tratamiento legal y seguro de los datos personales | Directorio de procesamiento, TOM, DSFA si corresponde, Oficial de protección de datos si corresponde |
| NIS2 / BSIG-nuevo | Probablemente no sea directamente obligatorio | Gestión de riesgos de ciberseguridad, obligaciones de notificación | Orientación voluntaria recomendada; Compruebe la relevancia de la cadena de suministro para clientes más grandes |
| Ley de IA de la UE | Parcialmente vinculante | Competencia en materia de IA (artículo 4), prohibiciones (artículo 5), transparencia (artículo 50) | la obligación de impartir formación de conformidad con el artículo 4; Obligaciones de alto riesgo no pertinentes |
| ISO/IEC 42001 | Voluntaria | Desarrollo de un sistema de gestión de la IA (AIMS) | El objetivo de certificación de la empresa es estructurar todo el proyecto |
| GeschGehG | Obligatorio | Medidas de confidencialidad adecuadas | Concepto de acceso y registro para datos de diseño/medición |
| BetrVG (si existe comité de empresa) | Encuadernación condicional | Codeterminación en sistemas con potencial de seguimiento (artículo 87, apartado 1, punto 6) | Participación temprana, política de uso de IA, si procede, como acuerdo operativo |
Nota: Esta visión general no sustituye a una evaluación jurídica caso por caso. En particular, la clasificación NIS2 depende no solo del número de empleados, sino también del volumen de negocios anual y del total del balance de la empresa, que aún no se conocen aquí (véase el capítulo 5.2).
4. Análisis detallado: Protección de datos (GDPR / BDSG)
4.1 Responsabilidad y bases jurídicas
Como operador del sistema local, la empresa es «responsable del tratamiento» con arreglo a la legislación en materia de protección de datos en el sentido del artículo 4, apartado 7, del RGPD para todos los datos personales tratados a través de Open WebUI. Podrán considerarse fundamentos jurídicos:
- Artículo 6, apartado 1, letra f), del RGPD (interés legítimo) para uso general como herramienta de eficiencia e investigación, siempre que se documente un equilibrio de intereses.
- § 26 BDSG en relación con el artículo 88 del RGPD para el tratamiento de los datos de los empleados en el contexto del uso (por ejemplo, registros de uso, historial rápido de empleados individuales).
- Artículo 6, apartado 1, letra b), del RGPD , en la medida en que los datos de los clientes se traten en el contexto de la ejecución del contrato (por ejemplo, preparación de informes de ensayo).
Recomendación: La base jurídica específica debe documentarse en el directorio de tratamiento para cada caso de uso (véase 4.5).
4.2 El procesamiento de pedidos es la ventaja central de la operación en las instalaciones
Mientras Open WebUI y los modelos de lenguaje conectado se operen exclusivamente localmente en su propia infraestructura y no se envíen solicitudes a API de modelos externos (por ejemplo, OpenAI, Anthropic, Google), no se producirá ningún procesamiento de pedidos con arreglo al artículo 28 del RGPD con respecto a un proveedor de IA. En principio, por lo tanto, no debe llevarse a cabo ningún contrato de procesamiento de pedidos (DPA) ni ningún examen de un traslado de un tercer país de conformidad con el capítulo V del RGPD para las operaciones básicas de IA.
Nota: Esta ventaja solo se aplica siempre y cuando la configuración se cumpla consistentemente. Tan pronto como se activan las funciones opcionales en la nube en Open WebUI (proveedores externos de búsqueda web, generación externa de imágenes / idiomas o un modelo de nube adicional como alternativa), los datos se transmiten una vez más a terceros para estas funciones, lo que requiere un AVV y, si es necesario, una evaluación de impacto de la transferencia (véase el capítulo 8.6). Esto debe ser técnicamente (desactivación en la configuración de administrador) y organizativamente (política de uso de IA).
4.3 Evaluación de impacto de la protección de datos (DSFA, art. 35 RGPD)
Si un DSFA es obligatorio depende del riesgo específico del procesamiento. Existen varias indicaciones para el uso de una aplicación de IA para una obligación DSFA o para una aplicación voluntaria recomendada:
- El uso de nuevas tecnologías (artículo 35, apartado 1, del RGPD) Los modelos lingüísticos de IA se consideran regularmente como tales de acuerdo con la práctica de supervisión generalizada.
- Posible evaluación sistemática y exhaustiva de los aspectos personales, siempre que la IA también se aplique a los documentos o solicitudes de personal en el futuro (excluido en el ámbito de aplicación actual, véase el punto 2.3).
- En sus orientaciones sobre las aplicaciones de IA, las autoridades de supervisión alemanas (Data Protection Conference, DSK) recomiendan regularmente la implementación de un DSFA, incluso por debajo del umbral legal obligatorio, como prueba de responsabilidad (artículo 5, apartado 2, del RGPD).
Recomendación: Un DSFA debe llevarse a cabo como parte de la fase 1 del proyecto, independientemente de la clasificación jurídica final de su obligación. También proporciona un elemento esencial para la posterior certificación ISO/IEC 42001 (evaluación de riesgos, véase el capítulo 7.5) y para cualquier gestión de riesgos NIS2 (capítulo 5).
4.4 Obligación de nombrar un delegado de protección de datos (artículo 38 de la BDSG)
Con arreglo al artículo 38, apartado 1, primera frase, de la BDSG, por lo general solo existe una obligación de orden si al menos veinte personas participan de forma permanente en el tratamiento automatizado de datos personales. Con 12 empleados, este umbral generalmente no debe alcanzarse.
Excepción importante: Con arreglo al artículo 38, apartado 1, segunda frase, de la BDSG, la obligación de realizar un pedido se aplica con independencia del número de empleados desde el momento en que se lleva a cabo el tratamiento, que está sujeto a una evaluación de impacto relativa a la protección de datos con arreglo al artículo 35 del RGPD. Si se afirma una obligación DSFA para el proyecto de IA como se recomienda en 4.3, esto también puede dar lugar a la obligación de nombrar un delegado de protección de datos, independientemente del tamaño de la empresa.
- Esta cuestión debe aclararse en una fase temprana durante el examen previo del DSFA con un especialista.
- Independientemente de una obligación legal, la designación voluntaria de una persona de contacto responsable (delegado de protección de datos interno o externo) se recomienda para una pyme de este tamaño en el contexto de la IA y, de todos modos, la ISO/IEC 42001 la recomienda en el sentido de funciones y responsabilidades claras (véase el capítulo 9).
Nota: A nivel federal, actualmente se está debatiendo que el artículo 38, apartado 1, de la BDSG debe suprimirse sin sustitución y que la obligación de realizar pedidos debe basarse exclusivamente en el enfoque basado en el riesgo del artículo 37 del RGPD (anuncio en el contexto de la «Agenda Federal de Modernización» de 4 de abril de 2018). diciembre de 2025, aplicación anunciada a finales de 2026, a partir de agosto de 2026 aún no en vigor). La situación jurídica actual debe reexaminarse en el momento de la aplicación.
4.5 Lista de actividades de tratamiento (artículo 30 del RGPD)
Para cada caso de uso basado en IA (por ejemplo, «asistente de chat interno», «documentación técnica de búsqueda de conocimientos RAG», «borradores de texto de comunicación al cliente»), debe crearse una entrada separada en el directorio de tratamiento, con información sobre la finalidad, los grupos de personas afectadas, las categorías de datos, la base jurídica, el período de almacenamiento, las medidas técnicas y organizativas y, en su caso, los destinatarios.
4.6 Medidas técnicas y organizativas (artículo 32 del RGPD)
En particular, deben aplicarse y documentarse las siguientes medidas para el funcionamiento in situ:
- Cifrado de datos en reposo (base de datos, almacenamiento vectorial, sistema de archivos) y en tránsito (TLS/SSL a través del proxy inverso, véase el capítulo 8.5).
- Concepto de rol y derechos en Open WebUI (administrador vs. roles de usuario, restricción de acceso a bases de conocimiento según sea necesario).
- Registro de eventos relevantes para la seguridad (accesos, cambios administrativos) teniendo en cuenta la limitación de la finalidad. Además, no hay control de comportamiento o rendimiento de los empleados individuales.
- Copias de seguridad regulares y cifradas con un concepto de recuperación definido.
- Segmentación de la red: El servidor de IA debe estar aislado en la red interna, sin acceso directo desde Internet sin VPN o proxy inverso seguro.
- Gestión de parches y versiones para Open WebUI, Ollama y la base del sistema operativo.
4.7 Derechos de los interesados y concepto de supresión
Dado que las bases de datos de conocimientos de las DAR también pueden contener datos personales (por ejemplo, personas de contacto en documentos de clientes, nombres en archivos adjuntos de correo electrónico), se requiere un concepto de eliminación que especifique cómo pueden implementarse técnicamente en la base de datos de vectores las solicitudes de información, corrección y eliminación (artículos 15 a 17 del RGPD). Recomendación: prever la selección/anonimización de contenidos obviamente personales pero no obligatorios antes de introducir documentos en la base de conocimientos.
4.8 Protección de datos de los empleados y codeterminación
La introducción de un sistema de IA, que en principio puede registrarse y evaluarse, puede estar sujeta a codeterminación en virtud del artículo 87, apartado 1, punto 6, de la BetrVG, siempre que haya un comité de empresa en la empresa (no necesariamente disponible para 12 empleados, pero es posible). Si existe un comité de empresa, debe participar en una fase temprana y debe celebrarse un acuerdo operativo sobre el uso de la IA. Si no hay un comité de empresa, se recomienda crear una política de uso de IA por escrito que regule de forma transparente lo que se registra y por qué (véase el capítulo 4.9).
4.9 Política de uso de IA para empleados
Debe establecerse una Directiva sobre la utilización de la IA como documento interno vinculante que abarque, entre otras cosas:
- Casos de uso permisibles e inadmisibles (por ejemplo, ninguna entrada de secretos comerciales estratégicos de terceros sin su divulgación, incluso si permanecen en las instalaciones).
- Prohibición de eludir las medidas técnicas de protección (por ejemplo, el uso privado de herramientas externas de IA para contenidos corporativos sujetos a confidencialidad).
- Manipulación de contenidos generados por IA (obligaciones de etiquetado, obligación de llevar a cabo controles técnicos antes de la reutilización, en particular para los datos de medición y ensayo).
- Información de transparencia sobre el registro y la evaluación de conformidad con el artículo 13/14 del RGPD.
5. Análisis detallado: NIS2 / BSIG-nuevo
5.1 Antecedentes jurídicos
La Directiva (UE) 2022/2555 de la UE (SRI 2) se transpuso en Alemania con un retraso significativo mediante la «Ley sobre la aplicación de la Directiva SRI 2 y sobre la regulación de los principios esenciales de la gestión de la seguridad de la información en la administración federal» (NIS2UmsuCG). La ley fue aprobada el día 5. Fue promulgada en la Gaceta de Leyes Federales el 6 de diciembre de 2025. entró en vigor el 1 de diciembre de 2025 sin un período transitorio; modifica fundamentalmente la BSI Act (BSIG-new). En toda Alemania, se estima que unas 29 500 empresas se ven directamente afectadas; la obligación de registrarse en el Portal BSI (activado el 6 de enero de 2026) expiró el 6 de marzo de 2026 para las entidades afectadas.
5.2 Prueba de aplicabilidad para la empresa
Las obligaciones SRI 2 se aplican a las entidades «importantes» y «particularmente importantes». La clasificación se lleva a cabo en dos etapas: primero sobre la afiliación sectorial (anexo I/II de la Directiva), y luego sobre las clases de tamaño.
Etapa 1 – Afiliación sectorial
La fabricación de instrumentos de medida, control, navegación e instrumentos similares pertenece al grupo C26 de la NACE («Fabricación de equipos de tratamiento de datos, productos electrónicos y ópticos»), que figura explícitamente en el anexo II de la Directiva SRI 2 como subsector de la «industria manufacturera» como otro sector crítico («entidad importante»). Por lo tanto, una empresa de metrología industrial está generalmente dentro del alcance de NIS2 en términos de alcance sectorial, pero la aplicabilidad final depende de la clase de tamaño (etapa 2).
Etapa 2 – Clase de tamaño
Los NEI2 excluyen generalmente de su ámbito de aplicación a las microempresas y las pequeñas empresas. La definición de pyme de la UE es pertinente:
| categoría | Empleados | Volumen de negocios anual | o balance total | Estado de NIS2 |
| micro | < 10 | ≤ 2 millones de euros | ≤ 2 millones de euros | Regularmente exceptuado |
| Pequeñas empresas | < 50 | ≤ 10 millones de euros | ≤ 10 millones de euros | Regularmente exceptuado |
| Mediana empresa | < 250 | ≤ 50 millones de euros | ≤ 43 millones de euros | Posibilidad de «instalación importante» |
Clasificación: Con 12 empleados, la empresa está por debajo del umbral de 50 personas para las «pequeñas empresas». Si, además, el volumen de negocios anual o el total del balance no supera los 10 millones de euros (lo que probablemente sea la norma para este tamaño de negocio, pero debe confirmarse sobre una base específica de la empresa), es poco probable que las obligaciones directas de SRI 2 se apliquen de acuerdo con los conocimientos actuales.
Independientemente de la exención de tamaño, la SRI 2 se aplica, no obstante, a determinados tipos de entidades, independientemente de su tamaño (incluidos los operadores de redes públicas de telecomunicaciones, los proveedores cualificados de servicios de confianza, los proveedores de servicios DNS/registradores de dominios de primer nivel, las administraciones públicas, las entidades clasificadas como críticas en virtud de la Ley de tejados KRITIS y las entidades que son los únicos proveedores de un servicio en Alemania que es importante para el mantenimiento de actividades sociales o económicas críticas). Ninguna de estas excepciones debería aplicarse normalmente a una pyme de este tamaño; Sin embargo, se recomienda una breve evaluación en la fase 1 del proyecto (véase el anexo A).
5.3 Pertinencia indirecta: Seguridad de la cadena de suministro
Incluso sin su propia obligación NIS2, la empresa puede verse afectada indirectamente: Los clientes obligados a la SRI 2 (por ejemplo, los principales proveedores de ingeniería mecánica o automoción que a su vez se consideran «importantes» o «entidades especialmente importantes») deben evaluar la seguridad de su cadena de suministro (artículo 21 de la Directiva SRI 2) y están transfiriendo cada vez más contractualmente los requisitos de seguridad a los proveedores, incluidos los socios más pequeños, como una pyme de medición. La seguridad de la información documentada y la gestión de riesgos de IA se están convirtiendo cada vez más en un factor competitivo y de licitación, independientemente de la propia obligación de NIS2.
5.4 Recomendación para el proyecto
- No realice un registro NIS2 formal mientras no se cumplan los umbrales (esfuerzo burocrático innecesario).
- Utilizar voluntariamente las medidas básicas de la SRI 2 de conformidad con el artículo 30 de la BSIG-neu (incluida la gestión de riesgos, los procesos de detección y notificación de incidentes, la gestión de copias de seguridad y emergencias, los conceptos de criptografía y cifrado, el control de acceso, la formación y la seguridad de la cadena de suministro) como orientación para la protección técnica del sistema de IA. Estos se ajustan en gran medida a los controles exigidos de todos modos para la norma ISO/IEC 42001 y el artículo 32 del RGPD (véanse los capítulos 4.6, 7.5 y 8.5).
- La posibilidad de registro voluntario con el BSI (para empresas no obligadas bajo el nuevo BSIG) puede verificarse opcionalmente si la empresa quiere anunciarse activamente con una mayor resistencia cibernética a los clientes.
- La clasificación por tamaño debe reevaluarse en caso de crecimiento futuro (superior a 50 empleados o 10 millones EUR en volumen de negocios / balance total), ya que esto puede dar lugar a una obligación de SRI 2.
6. Análisis detallado: Ley de IA de la UE
6.1 Papel de la empresa
En el uso previsto de Open WebUI con modelos de lenguaje abierto previamente entrenados (por ejemplo, a través de Ollama), la empresa actúa en virtud de la legislación sobre protección de datos y productos como «operador» (empresario) en el sentido del artículo 3, apartado 4, del Reglamento de IA, no como «proveedor» (proveedor). Las obligaciones del proveedor (evaluación de la conformidad, documentación técnica del modelo) se aplican a los fabricantes de modelos, no a la pyme solicitante, a menos que la empresa adapte sus propios modelos de manera tan fundamental o los transmita en su propio nombre que se convierta en el propio proveedor (no previsto en el ámbito de aplicación previsto).
6.2 Prácticas prohibidas (artículo 5 del Reglamento de IA)
Las prohibiciones de determinadas prácticas de IA (incluida la puntuación social, determinadas formas de categorización biométrica y los sistemas de manipulación) son aplicables desde el 2 de febrero de 2025. Para el caso de uso previsto de la asistencia interna y la búsqueda de conocimientos, no se observa ningún contacto con estas prohibiciones.
6.3 Clasificación como sistema de IA de alto riesgo (anexo III)
Un asistente interno de IA para el trabajo de texto y la búsqueda de conocimientos técnicos no entra en los casos de uso de alto riesgo enumerados en el anexo III del Reglamento de IA (incluida la selección de personal, la evaluación crediticia, la identificación biométrica y la gestión de infraestructuras críticas). Mientras se cumpla la demarcación descrita en el capítulo 2.3, el caso de uso no es de alto riesgo.
Nota: Independientemente de esto, el denominado «Ómnibus digital sobre IA», un acuerdo político alcanzado por el Consejo y el Parlamento Europeo el 7 de mayo de 2026, tiene todas las obligaciones para los sistemas de IA independientes de alto riesgo establecidas en el anexo III de todos modos desde agosto de 2026 hasta el segundo. Diciembre de 2027 aplazado (productos del anexo I: 2 de agosto de 2028). La adopción formal de este documento en el Diario Oficial de la UE estaba pendiente (agosto de 2026); Hasta la publicación final, el calendario original seguirá aplicándose formalmente. Para el caso de uso descrito aquí, esto es secundario de todos modos, ya que no existe una clasificación de alto riesgo.
6.4 Deberes que ya se aplican
Artículo 4 del Reglamento sobre IA: alfabetización en materia de IA: Desde el 2 de febrero de 2025, se ha exigido a los proveedores y operadores de sistemas de IA que garanticen una competencia suficiente en materia de IA en su personal y en otras personas que participan en la operación y el uso de sistemas de IA en su nombre. Esta obligación se aplica independientemente del tamaño de la empresa y está consagrada en el plan del proyecto como una tarea obligatoria (formación de todos los usuarios antes de iniciar la producción) (véase el capítulo 10, fase 4).
Artículo 53 del Reglamento de IA – Obligaciones en materia de IAGP: Los requisitos de transparencia y documentación para los modelos de IA de uso general han sido aplicables desde agosto de 2025 y la aplicación comenzará en agosto de 2026. Estas obligaciones se imponen principalmente a los proveedores de modelos (por ejemplo, los desarrolladores de los modelos abiertos utilizados), no al usuario pyme como operador.
Artículo 50 del Reglamento de IA. Obligaciones de transparencia: A partir del 2 de agosto de 2026, se aplicará la obligación de identificar los contenidos generados o modificados por IA, siempre que se utilicen externamente (por ejemplo, con respecto a los clientes). Esto es pertinente una vez que el asistente de IA se utiliza para preparar textos orientados al cliente y debe regularse en la Directiva sobre el uso de la IA (capítulo 4.9).
6.5 Conclusión
Las obligaciones jurídicas directas en virtud de la Ley de IA de la UE son manejables para el caso de uso previsto. La tarea concreta más importante es garantizar la competencia en materia de IA de conformidad con el artículo 4 del Reglamento de IA mediante la formación. De todos modos, los elementos de gobernanza que tienen sentido para la Ley de IA (funciones, evaluación de riesgos, documentación, transparencia) se ajustan en gran medida a los requisitos de la norma ISO/IEC 42001 (capítulo 7) y deben desarrollarse de forma sinérgica.
7. ISO/IEC 42001 – Vía hacia la certificación
7.1 ¿Qué es ISO/IEC 42001?
ISO/IEC 42001:2023 es la primera norma internacional para un Sistema de Gestión de Inteligencia Artificial (AIMS). Sigue las normas ISO 9001 (calidad) e ISO/IEC 27001 (seguridad de la información) de la estructura de alto nivel (HLS) de las normas del sistema de gestión ISO y está estructurado de acuerdo con el ciclo PDCA (Plan-Do-Check-Act). El estándar es aplicable en todas las industrias y está diseñado para organizaciones de todos los tamaños que desarrollan, operan o utilizan sistemas de IA.
7.2 Beneficios para la Compañía
- Pruebas estructuradas de un uso responsable y controlado de la IA hacia los clientes, en particular hacia los socios proveedores más grandes y los poderes adjudicadores, donde la ISO 42001 es cada vez más solicitada como criterio de licitación o señal de confianza.
- Preparación sistemática para las futuras obligaciones de la Ley de IA de la UE: La documentación del AIMS (evaluación de riesgos, funciones, controles) puede reutilizarse para la prueba de conformidad.
- Sinergias con los sistemas de gestión existentes: Las empresas de tecnología de medición a menudo ya tienen un sistema de gestión de calidad de acuerdo con ISO 9001 o / e ISO / IEC 17025 (laboratorios de calibración), la estructura HLS permite una amplia integración en lugar de un sistema paralelo.
- Impacto interno: Las responsabilidades claras y los procesos documentados reducen el riesgo de uso indebido, violaciones de datos y pérdida de conocimiento en una pyme de este tamaño.
7.3 Definir el alcance (ámbito de aplicación)
Recomendación sobre el alcance de la certificación: «Provisión y funcionamiento de un sistema interno de asistencia de IA alojado en las instalaciones basado en una interfaz web abierta y modelos lingüísticos operados localmente, incluida la búsqueda de conocimientos basada en la recuperación (RAG) para los empleados de la empresa in situ [ubicación]». Un alcance estrecho y realista acelera significativamente la certificación sobre un AIMS para toda la empresa para todas las aplicaciones de IA imaginables.
7.4 Hoja de ruta de certificación
Para una pyme de este tamaño, se debe considerar un plazo realista de aproximadamente 9-12 meses hasta la madurez de la certificación (las referencias indican 6-18 meses dependiendo del punto de partida). La hoja de ruta se divide en cinco pasos clave consagrados en el plan de fases (capítulo 10):
| paso | contenidos | resultado |
| 1. Análisis de brechas | Concordancia del estado real con los capítulos 4 a 10 de la norma ISO/IEC 42001 y el anexo A | Lista de medidas con priorización |
| 2. Equipo del proyecto & Gobernanza | Nombramiento del controlador AIMS, adopción de la política de IA | Política de IA, matriz de funciones |
| 3. Evaluación de riesgos | Evaluación de riesgos e impacto específica de la IA por caso de uso | Registro de riesgos (capítulo 11) |
| 4. documentación | Manual AIMS, instrucciones de procedimiento, pruebas (formación, auditorías) | Documentación completa de AIMS |
| 5. Auditorías internas & Revisión | Auditoría interna, revisión de la gestión, medidas correctoras | Informe de auditoría, aprobación para la certificación |
7.5 Requisitos clave de un vistazo
Al igual que con ISO 9001/27001, la norma se divide en siete capítulos principales:
- Contexto de la organización (capítulo 4): Partes interesadas, definición del ámbito de aplicación.
- Liderazgo (capítulo 5): Política, funciones y responsabilidades en materia de IA, a menudo en doble función para doce empleados (véase el capítulo 9).
- Planificación (capítulo 6): Riesgos y oportunidades, objetivos de la IA, evaluación de impacto de la IA por sistema.
- Apoyo (capítulo 7): Recursos, competencia (interfaz con el artículo 4 del Reglamento sobre IA), sensibilización, comunicación e información documentada.
- Operación (capítulo 8): planificación operativa y gestión del ciclo de vida de la IA, gestión de proveedores/terceros.
- Evaluación del rendimiento (capítulo 9): Supervisión, auditoría interna, revisión de la gestión.
- Mejora (capítulo 10): Lidiar con las no conformidades, la mejora continua.
Además, el anexo A define controles específicos (por ejemplo, sobre la Directiva de IA, la gestión de recursos, los datos para los sistemas de IA, la transparencia hacia las partes interesadas, el uso de componentes de terceros o de código abierto, como los modelos Ollama, y la evaluación de las repercusiones sociales). Estos controles deben asignarse 1:1 a la arquitectura técnica descrita en el capítulo 8.
7.6 Proceso de certificación
- Auditoría de la fase 1: Revisión de documentos por parte del organismo de certificación (auditoría del manual de AIMS, política de IA, registro de riesgos, instrucciones de procedimiento).
- Auditoría de la fase 2: Pruebas de eficacia sobre el terreno o a distancia (entrevistas, muestreo, verificación técnica de los controles aplicados).
- Emisión de certificados tras una auditoría exitosa, validez de normalmente 3 años.
- Auditorías anuales de vigilancia para mantener el certificado.
- Auditoría de recertificación al final del ciclo trienal.
7.7 Elección del organismo de certificación
Se recomienda que solo se encargue un organismo de certificación acreditado por el organismo de acreditación alemán (DAkkS) o un organismo de acreditación europeo equivalente (por ejemplo, empresas TÜV, DNV, DEKRA o proveedores comparables). La selección concreta debe realizarse a través de al menos dos o tres ofertas comparativas, incluida la experiencia con pymes y empresas manufactureras).
8. Arquitectura técnica e implementación
La base técnica sigue el enfoque propuesto por la compañía (Open WebUI + Ollama, basado en Docker) y se complementa con las salvaguardias necesarias para una configuración segura y certificada de PYME.
8.1 Arquitectura del objetivo
Recomendamos una implementación de Docker Compose en un servidor dedicado físicamente en la empresa (alternativamente: Mini Server / Mac Mini Class para la entrada, con opción de actualización). El backend LLM no requiere una conexión a Internet saliente para la operación principal. Una operación en gran medida netzisolierte ("air-gap-close") es posible y también se recomienda desde el punto de vista de la protección de datos y la seguridad.
8.2 Descripción general de los componentes
| componente | función | Recomendación para el proyecto |
| Abrir WebUI | Frontend, gestión de usuarios/derechos, interfaz RAG | Ejecutar version-pinned (sin etiqueta «:main»), actualizaciones controladas regularmente |
| Ollama | Tiempo de ejecución del modelo local | Selección de modelos de acuerdo con el Capítulo 8.4, sin conexión automática a la nube |
| Base de datos vectorial (RAG) | Almacenamiento/búsqueda en la base de conocimientos | Comience con ChromaDB integrado; Considere Qdrant a medida que crece el stock de documentos |
| Proxy inverso (nginx/Caddy) | Acceso cifrado y controlado en la red de la empresa | Certificado TLS, acceso solo desde la red interna / VPN |
| Gestión de usuarios | autenticación | Si es posible, conexión al directorio existente (por ejemplo, a través de SSO / LDAP), de lo contrario cuentas individuales por empleado |
8.3 Planificación de hardware
Para 12 usuarios con uso predominantemente secuencial (sin operación masiva de alta carga), un servidor con una GPU de consumidor a prosumidor (por ejemplo, clase RTX 4000/4060 Ti 16 GB o comparable) suele ser suficiente para modelos en el rango de 7-14 mil millones de parámetros en forma cuantificada. Para requisitos de mayor calidad o un uso más simultáneo, se debe presupuestar una GPU con más VRAM (24 GB +). La operación pura de la CPU es posible, pero notablemente más lenta para un uso productivo con varios usuarios simultáneos y no se recomienda. El dimensionamiento del hormigón debe validarse después de una fase piloto corta (fase 3) sobre la base de la carga real en uso.
8.4 Selección de modelos - Criterios
La selección concreta del modelo es una decisión técnica en el transcurso del proyecto, pero debe hacerse y documentarse sobre la base de los siguientes criterios (también pertinentes para el anexo A de la norma ISO 42001, «Datos de los sistemas de IA»):
- Pesos de modelo abiertos y claramente licenciados (consulte los términos de la licencia para uso comercial).
- Calidad en alemán y en contextos técnico-técnicos (terminología de medición tecnológica).
- Necesidades de recursos para que coincidan con el hardware disponible (véase 8.3).
- Origen rastreable e historial de actualización/apoyo del proveedor del modelo (la obligación de documentación en virtud del artículo 53 del Reglamento de IA se aplica al proveedor, pero debe servir como criterio de selección para el operador).
- No hay telemetría automática ni contacto con servidores externos en funcionamiento regular.
8.5 Concepto de seguridad
- Segmentación de red (VLAN propia para el servidor AI), sin acceso directo a Internet al backend.
- Acceda solo a través de proxy inverso seguro con certificado TLS, idealmente solo accesible desde la red interna o a través de la VPN de la empresa.
- Concepto de función/derechos: Función de administrador limitada a los administradores de TI, usuarios estándar sin acceso a la configuración del sistema.
- Registro de eventos relevantes para la seguridad con un período de retención definido y conforme con la protección de datos.
- Copias de seguridad regulares y auditadas (principio 3-2-1 recomendado) y proceso de recuperación documentado.
- Proceso definido de parches y actualizaciones para todos los componentes (Open WebUI, Ollama, sistema operativo, imágenes de base de contenedores).
- Estas medidas se ajustan en líneas generales a las medidas de referencia voluntarias SRI 2 (capítulo 5.4) y a los requisitos del artículo 32 del RGPD (capítulo 4.6).
8.6 Control y desactivación de las funciones críticas de la nube
Open WebUI ofrece numerosas extensiones opcionales (proveedores externos de búsqueda web, generación externa de imágenes, servicios externos de voz / transcripción, modelos en la nube como una opción adicional). Estas funciones son eficientes, pero contradicen el concepto de protección de datos y on-premise de este proyecto tan pronto como transmiten datos personales o confidenciales a terceros.
Nota: Recomendación: Desactive todas las extensiones externas/basadas en la nube en la interfaz de administración de forma predeterminada. No obstante, si se van a utilizar funciones individuales en la nube en el futuro (por ejemplo, una búsqueda web externa para búsquedas no confidenciales), esta debe evaluarse de antemano con arreglo a la legislación en materia de protección de datos (contrato de tratamiento de contratos, evaluación de impacto de la transferencia, si procede en relación con terceros países) y regularse explícitamente en la Directiva sobre el uso de la IA.
9. Organización y roles del proyecto
En una empresa con 12 empleados, una separación completa de todos los roles entre diferentes personas no es realista. Sin embargo, ISO/IEC 42001 requiere responsabilidades claramente documentadas, incluso si una persona desempeña múltiples roles en la unión personal. El factor decisivo es la fijación escrita, no el número de cabezas.
| rol | responsabilidad | Recomendación de nombramiento (12-MA-SME) |
| Gestión/gestión de proyectos | Responsabilidad general, publicación de la política de IA, presupuesto | gestión |
| AIMS/Gestor(es) de IA | Configuración y mantenimiento del sistema de gestión de la IA, persona de contacto para las auditorías | Gestión o gerente designado, si es necesario con apoyo externo |
| Administración de TI | Operación técnica, configuración de seguridad, gestión de parches | Responsabilidad de TI interna o proveedor de servicios de TI externo |
| Persona de contacto para la protección de datos / OSD | DSFA, directorio de procesamiento, consultas de los interesados | Se recomienda el nombramiento externo del delegado de protección de datos (véase el capítulo 4.4) |
| Usuarios clave / multiplicadores | Comentarios técnicos de los departamentos, apoyo a la formación | 1-2 profesionales experimentados |
| Consultoría externa ISO 42001 (opcional) | Análisis de brechas, preparación de auditorías | Participar caso por caso, especialmente antes de la auditoría de la Etapa 1 |
Plan de fase e hitos
El período total hasta la madurez de la certificación es de aproximadamente 10-12 meses. Varias fases se están ejecutando deliberadamente en paralelo para representar de manera realista las limitadas capacidades de personal de una operación de 12 personas. El desarrollo del AIMS (fase 5) comienza ya durante la implementación técnica y se extiende hasta la madurez de la auditoría interna.
| # | Fase | mes | Principales resultados |
| 0 | Inicio del proyecto & scoping | 1 | Orden del proyecto, definición del objetivo, definición del alcance ISO 42001, aprobación del presupuesto |
| 1 | Trabajo jurídico básico | 1-2 | DSFA, aclaración de la obligación del OSD, directorio de procesamiento, verificación corta NIS2, política de uso de IA (proyecto) |
| 2 | Concepto técnico & Adquisiciones | 2-3 | Selección de hardware, concepto de red/seguridad, selección de modelos, adquisición |
| 3 | Implementación & Operación piloto | 3-4 | Instalación Abrir WebUI/Ollama, configuración RAG, operación de prueba con el grupo central |
| 4 | Implementación & Formación | 4-5 | Formación de todos los empleados (incluido el artículo 4 del Reglamento de IA), despliegue productivo, Directiva final sobre el uso de la IA |
| 5 | Estructura AIMS según ISO 42001 | 3-8 | Política de IA, matriz de funciones, registro de riesgos, documentación (se ejecuta en paralelo desde el inicio del proyecto piloto) |
| 6 | Auditorías internas & revisión de la gestión | 8-9 | Auditoría interna, acciones correctivas, aprobación por parte de la dirección |
| 7 | Auditoría de certificación (fase 1 + 2) | 9-11 | Selección del organismo de certificación, revisión de documentos, auditoría in situ/a distancia |
| 8 | Emisión de certificados & Operación | de las 11 a las 12 horas | Certificado, operación en curso, auditoría de monitoreo anual, mejora continua |
11. Gestión de riesgos
El siguiente registro de riesgos también forma parte de la evaluación de riesgos exigida por el capítulo 6 de la norma ISO/IEC 42001 y debe actualizarse continuamente durante el proyecto.
| riesgo | categoría | Es verdad. | impacto | medida |
| Activación accidental de plugins en la nube (búsqueda web, API externa) | privacidad | consignación | Alto | Configuración de administrador de bloques, política de uso de IA, verificación de configuración regular |
| Baja aceptación por parte de los empleados | Organización | consignación | consignación | Participación temprana, formación comprensible, usuarios clave como multiplicadores |
| Insuficiente rendimiento del hardware en la práctica | técnica | consignación | consignación | Fase piloto para la validación de la carga antes de la expansión completa, planificando el hardware escalable |
| Flujo de conocimiento / secreto a través de entradas rápidas en la futura expansión de la nube | Protección de datos / GeschGehG | Bajo (al cumplir con 8.6) | Alto | Desactivación técnica, política clara, formación sobre obligaciones de confidencialidad |
| Resultados incorrectos de la IA en la interpretación técnica de los datos de medición (alucinación) | Técnica / calidad | consignación | Alto | Obligación obligatoria de realizar ensayos técnicos antes de la reutilización, no publicación automatizada de textos de IA en los informes de ensayo |
| Retraso debido a la limitada capacidad interna (operación 12-MA) | proyecto | Alto | consignación | Programación realista, soporte externo ad hoc para protección de datos e ISO 42001 |
| Despreciación del modelo / descontinuación de la licencia de un modelo abierto usado | técnica | bajo | consignación | Documentar la selección del modelo, prever el cambio al modelo alternativo como plan de emergencia |
| Falta de madurez de la certificación en el período previsto | Proyecto / certificación | consignación | consignación | Análisis de brechas tempranas, auditorías internas iterativas en lugar de big bang antes de la etapa 1 |
12. Planificación de costos y recursos
La siguiente información es una guía aproximada basada en los anchos de banda estándar del mercado para consultoría, hardware y certificación en Alemania (a partir de 2026) y no reemplaza ofertas específicas. Se recomienda obtener al menos dos o tres ofertas comparativas para los puestos de alto costo (consulta, certificación) antes de la aprobación del presupuesto.
| posición | tipo | Estimación aproximada | observación |
| Hardware (servidor/GPU, componentes de red) | Único | aprox. 3 000 – 12 000 EUR | dependiendo del tamaño del modelo y de la carga del usuario; El software en sí es de código abierto (gratuito) |
| Soporte externo de configuración de TI (opcional) | Único | aprox. 1 500 – 5 000 EUR | Configuración de Docker, copia de seguridad, configuración RAG, si no está cubierta internamente |
| Responsable externo de protección de datos (si no es interno) | En curso, anual | aproximadamente entre 2 000 y 6 000 EUR/año | dependiendo del tamaño y del proveedor, para una pyme de este tamaño |
| Consultoría externa ISO 42001 (análisis de Gap, preparación de auditoría) | Único | aprox. 4 000 – 15 000 EUR | depende en gran medida de los conocimientos previos internos y de los sistemas de gestión existentes (por ejemplo, ISO 9001) |
| Auditoría de certificación (fase 1 + 2) | Una sola vez, luego anualmente (monitoreo) | aproximadamente entre 4 000 y 10 000 EUR | dependiendo del organismo de certificación y del ámbito de aplicación; Las auditorías anuales de seguimiento son más baratas |
| Formación de los empleados (competencia de IA, uso) | Único + en curso | aprox. 1 000 – 3 000 EUR | Se puede llevar a cabo en parte internamente. |
| Tiempo de personal interno (gestión de proyectos, TI, departamentos) | Continuamente durante la duración del proyecto | No cuantificado en euros | Factor significativo para 12 empleados: se requiere una planificación realista de la capacidad |
13. Criterios de éxito
- Los 12 empleados están capacitados y utilizan activamente el asistente de IA para al menos un caso de uso documentado.
- No se han notificado incidentes de protección de datos o de confidencialidad relacionados con el uso de la IA.
- El directorio de procesamiento, la política de uso de DSFA y AI están completamente documentados y actualizados.
- Finalización satisfactoria de las auditorías de las fases 1 y 2 y expedición del certificado ISO/IEC 42001 en el plazo previsto.
- Comentarios positivos de los empleados sobre la usabilidad (por ejemplo, a través de una breve encuesta interna después de 1 y 3 meses de operación productiva).
- Ahorro de tiempo demostrable en al menos un caso de uso definido (por ejemplo, investigación documental, borradores de textos, casos de soporte estándar).
14. Próximos pasos (primeros 30 días)
- Aprobar formalmente la orden del proyecto por parte de la gerencia, definir aproximadamente el presupuesto.
- Nombrar administradores de AIMS/AI (también es posible en unión personal con la gerencia).
- Póngase en contacto con asesores jurídicos o consultores externos de protección de datos para el examen preliminar de la DSFA y la aclaración de la obligación del OSD.
- Realizar y documentar internamente el control abreviado de la SRI 2 (anexo A), en particular comprobar el volumen de negocios anual/el total del balance con respecto a los umbrales.
- Capture los requisitos técnicos iniciales (número de usuarios, casos de uso deseados, hardware existente) y obtenga ofertas para el hardware del servidor.
- Comience un estudio de mercado aproximado de los organismos de certificación ISO / IEC 42001 y, si es necesario, de las empresas de consultoría (comparación de ofertas).
- Reunión inicial con todos los empleados para el anuncio del proyecto y la aclaración de las expectativas.
15. apéndice
Anexo A – Control de aplicabilidad de la SRI 2
- ¿La empresa suele emplear a 50 o más personas? (Si no es así, siga comprobando)
- ¿El volumen de negocios anual supera los 10 millones de euros o el balance general supera los 10 millones de euros? (Si no hay → NIS2 generalmente no es aplicable)
- ¿Es la compañía el único proveedor de un servicio crítico para Alemania, proveedor de servicios de confianza calificado, proveedor de TLD / DNS, proveedor de telecomunicaciones o clasificado como crítico bajo la Ley de Techos KRITIS? (En caso negativo → sin obligación especial independiente del tamaño)
- ¿Un cliente significativo requiere contractualmente una prueba de seguridad relacionada con NIS2 en la cadena de suministro? (En caso afirmativo → Se recomiendan orientaciones voluntarias sobre las medidas de referencia NIS2, independientemente de su propia obligación)
Anexo B – Examen previo de la DSFA (control abreviado con arreglo a los criterios del artículo 35, apartado 3, del RGPD / DSK)
- ¿Se evalúan sistemáticamente los datos de comportamiento o rendimiento de los empleados individuales?
- ¿Se tratan o almacenan en la base de conocimientos categorías especiales de datos personales (artículo 9 del RGPD)?
- ¿Se utiliza una tecnología novedosa con una evaluación de riesgos poco clara (los modelos de lenguaje de IA se consideran regularmente como tales)?
- ¿Se pueden procesar o buscar datos a gran escala (muchos documentos/personas) automáticamente?
- Si varias respuestas «sí» dan lugar a un aumento del riesgo, debe llevarse a cabo un DSFA o, al menos, documentarse por qué no es necesario.
Anexo C – Bases jurídicas principales (descripción general)
- Reglamento (UE) 2016/679 (Reglamento general de protección de datos, RGPD)
- Ley Federal de Protección de Datos (BDSG), en particular los artículos 26 y 38
- La Directiva (UE) 2022/2555 (Directiva SRI 2) y la Ley alemana de transposición NIS2UmsuCG (nueva Ley BSI, BSIG-neu), en vigor desde 6. Diciembre de 2025
- Reglamento (UE) 2024/1689 (Reglamento de IA / Reglamento de IA de la UE), en particular sus artículos 4, 5, 50 y 53.
- Ómnibus digital sobre IA → acuerdo político de 7 de mayo de 2026 sobre el aplazamiento del plazo para las obligaciones de alto riesgo (pendiente de adopción formal a partir de agosto de 2026)
- ISO/IEC 42001:2023 → Sistema de gestión de inteligencia artificial
- Ley para la Protección de Secretos Comerciales (GeschGehG)
- Ley de Constitución de Obras (BetrVG), en particular el artículo 87, apartado 1, punto 6 (si existe un comité de empresa)