
## La fábrica conectada no se apaga por “un virus”: se apaga por decisiones invisibles
Cuando una empresa industrial me dice “tenemos miedo a un ciberataque”, yo no empiezo hablando de amenazas.
Empiezo hablando de algo más tangible:
-
- paradas
-
- plazos que se rompen
-
- retrabajos
-
- entregas reprogramadas
-
- y margen que se evapora.
Porque en una fábrica conectada, el incidente no llega con una sirena. Llega con una normalidad peligrosa: un acceso que no debía existir, un permiso heredado, una contraseña compartida, un equipo “temporal” que se queda para siempre, una excepción que nadie documenta.
Y un día, la operación descubre que su continuidad depende de cosas que nunca se discutieron en dirección.
## Qué entiendo yo por “fábrica conectada” (y por qué cambia el riesgo)
Fábrica conectada no es solo tener máquinas con red. Es tener procesos donde conviven:
-
- sistemas de planificación y gestión
-
- estaciones de trabajo
-
- redes industriales
-
- dispositivos de captura (lectores, tablets, sensores)
-
- y flujos de datos que se cruzan para ganar velocidad.

Esa velocidad es real. Pero trae una consecuencia:
si los accesos y las identidades no están gobernados, la fábrica se vuelve frágil.
No frágil por tecnología. Frágil por falta de límites.
## El error de enfoque más común: comprar “seguridad” como si fuera un producto
He visto demasiadas empresas tratar la ciberseguridad como si fuera:
-
- un antivirus
-
- una caja
-
- un proveedor “que lo lleva”.
Pero la ciberseguridad operativa no se compra como un objeto. Se construye como una disciplina.
Y, sobre todo, se construye con una pregunta incómoda:
¿qué puede tocar quién, y qué pasa si se equivoca?
Si no puedes responder, tu continuidad está basada en confianza.

## Lo que realmente está en juego: continuidad, promesa y reputación
En una empresa por proyecto, la cadena es sensible:
-
- si se para la fábrica, se mueven fechas
-
- si se mueven fechas, se dispara coordinación
-
- si se dispara coordinación, se degradan decisiones
-
- si se degradan decisiones, aparece retrabajo
-
- y el retrabajo come margen.
Por eso yo no hablo de “ciberseguridad” como tema de IT. Hablo de:
-
- continuidad operativa
-
- capacidad real
-
- promesa defendible.
Y un principio manda sobre todos:
lo que no está delimitado, se convierte en incidente.

## La frontera OT/IT: donde nace la mayoría de los problemas
Sin entrar en tecnicismos, hay dos mundos:
-
- el mundo “de gestión” (usuarios, aplicaciones, documentos, correo, ERP/CRM)
-
- y el mundo “de operación” (máquinas, control, producción, captura).
Cuando esos mundos se conectan, es normal: quieres datos, trazabilidad, visibilidad.
El riesgo aparece cuando la conexión no tiene reglas claras, y se convierte en un “puente” informal:
-
- accesos que atraviesan sin control
-
- equipos personales conectados donde no deben
-
- herramientas remotas sin trazabilidad
-
- y “excepciones” que se vuelven rutina.
Mi señal de alerta no es técnica. Es cultural:
cuando la fábrica funciona “porque alguien sabe” y no porque el sistema impone límites.
## “No nos va a pasar” suele significar “no lo veríamos venir”
Otra realidad: muchas empresas creen que estarían a salvo porque:
-
- “no somos objetivo”
-
- “no guardamos secretos”
-
- “somos pequeños”.
Pero el impacto no depende de ser objetivo. Depende de ser vulnerable.
Y lo más peligroso es que un incidente grave no siempre se ve como “ciberataque”. A veces se ve como:
-
- un lunes raro
-
- un equipo que “no entra”
-
- un sistema que “va lento”
-
- una orden que “no aparece”
-
- un fichero que “no abre”.
Si no tienes señales e indicadores operativos, lo llamas “problema informático”… hasta que ya es tarde.
## Los 9 síntomas que me dicen que la fábrica está expuesta (sin tocar nada)
Si quieres detectar riesgo sin montar un proyecto, mira esto:
- Contraseñas compartidas para equipos o accesos críticos.
- Usuarios genéricos (“operario”, “admin”, “taller”) sin trazabilidad individual.
- Permisos heredados (“déjalo así que funciona”).
- Acceso remoto sin registro claro de quién entró y qué hizo.
- Equipos sin dueño (nadie sabe quién los mantiene).
- Copias de seguridad que “suponen” que están bien, pero nadie prueba recuperación.
- Actualizaciones que se posponen indefinidamente por miedo a parar.
- Datos duplicados entre sistemas (cada uno con su verdad).
- Incidentes menores repetidos que se normalizan (“siempre pasa”).
Cada uno de estos síntomas no es “un fallo técnico”. Es un indicador de gobernanza débil.


## El núcleo real: identidades, permisos y trazabilidad
Si me obligas a quedarme con una sola capa, me quedo con esta:
identidad + permisos + trazabilidad.
Porque la mayoría de los daños no ocurren por “hackers”. Ocurren por:
-
- accesos demasiado amplios
-
- cambios sin rastro
-
- y decisiones imposibles de auditar.
Yo lo aterrizo con tres preguntas simples:
### 1) ¿Quién es la persona?
No “el puesto”. La persona. Con su identidad.
### 2) ¿Qué puede hacer exactamente?
No “acceder”. Qué puede leer, editar, ejecutar, aprobar.
### 3) ¿Qué evidencia queda?
Si mañana hay una incidencia, ¿puedes reconstruir qué pasó sin depender de memoria?
Cuando estas tres están claras, la empresa deja de vivir en suposiciones.
## El mito de la “autonomía total”: el sistema necesita gates
En operación real, no todo puede ser automático, ni todo puede ser manual.
Lo que yo busco es equilibrio:
-
- lo rutinario puede fluir
-
- lo crítico pasa por un gate
-
- y lo irreversible exige aprobación.
No es burocracia. Es protección del margen.
El gate es la línea que evita que una mala acción (o un error humano) se convierta en una parada.
## Qué se rompe primero cuando hay un incidente
En mi experiencia, lo primero que se rompe no es “la tecnología”. Es la coordinación:
-
- la fábrica no sabe qué priorizar
-
- la oficina no sabe qué prometer
-
- compras no sabe qué confirmar
-
- y dirección no sabe qué creer.
El problema no es el evento. Es la falta de un marco para decidir bajo presión.
Por eso, para mí, ciberseguridad en fábrica conectada es también gestión de crisis: capacidad de decidir con evidencia.

## Preguntas de diagnóstico que uso para medir tu “radio de impacto”
Sin implementar nada, estas preguntas ya te dan claridad:
1) Si mañana cae un sistema clave, ¿qué parte de la producción puede seguir?
2) ¿Cuánto tiempo tardas en saber qué pedidos están en riesgo?
3) ¿Existe una lista clara de “lo crítico” (máquinas, estaciones, servicios, accesos)?
4) ¿Quién puede parar producción y quién puede reanudarla?
5) ¿Qué acceso remoto existe hoy y quién lo audita?
6) ¿Puedes restaurar copias y demostrarlo con una prueba reciente?
7) Cuando hay un cambio, ¿queda rastro y aprobación?
8) ¿Qué harías si descubres que dos sistemas tienen “verdades” distintas?
9) ¿Tu equipo sabe a quién llamar y qué decidir primero?
Si aquí hay dudas, no es culpa del equipo. Es una señal de que falta diseño.
## Cierre: la seguridad no es un proyecto de miedo, es un proyecto de continuidad
Yo no busco asustar a nadie. Busco evitar que la empresa viva de heroísmo.
En una fábrica conectada, la ciberseguridad no es un “extra”. Es parte de la promesa:
-
- promesa de plazo
-
- promesa de calidad
-
- promesa de respuesta
-
- promesa de continuidad.
Si quieres, lo reviso contigo en 15 minutos: identifico tus puntos de exposición más probables (sin drama), el “radio de impacto” real de un incidente, y qué criterios usar para decidir por dónde empezar sin paralizarte.








