Cómo se estructura TI para un proyecto minero sin área de TI

Varios cientos de empleados en nómina. Contabilidad pidiendo cierres, auditoría pidiendo evidencia, contratistas entrando y saliendo, correo corporativo para todos, y una base de datos geológica de la que depende cuánto vale el proyecto entero. Todo eso ya está operando antes de que salga la primera tonelada.

Lo que normalmente no está todavía es el área de TI.

Lo que hay es una superintendencia —a veces una sola persona, sin staff— llevando al mismo tiempo trámites, compras, proveedores, contratistas y, de pendiente, las decisiones de infraestructura que van a condicionar los próximos diez o quince años de operación. Si te suena, es porque es la contradicción de origen de casi cualquier greenfield: los requisitos de empresa mediana llegan antes que la estructura para atenderlos.

Así que la pregunta práctica no es qué implementar, sino en qué orden. Y el criterio es uno solo, así que va de entrada:

Hay decisiones que hoy son baratas y después del arranque de planta son caras o directamente irreversibles. Esas son las que hay que tomar primero, aunque parezcan lejanas.

1. Identidad primero, porque es lo más caro de rehacer

Si de toda esta lista solo alcanzas a hacer una bien, que sea esta.

De todo lo que se implementa en esta etapa, el plano de identidad es lo que tiene mayor costo de reversión. Todo lo demás cuelga de ahí: acceso a archivos, correo, aplicaciones sectoriales, respaldos, y más adelante los sistemas de planta.

La primera decisión de fondo es el modelo. Muchos proyectos arrancan enrolando los equipos de usuario directamente en la nube y asumen que con eso resolvieron identidad. Funciona bien para portátiles y escritorios. Deja de funcionar en cuanto aparece el primer servidor Windows que exige Active Directory para operar.

El directorio local no se va a ir. El join a Entra ID no está soportado para Windows Server fuera de máquinas virtuales en Azure, y tampoco para servidores con rol de controlador de dominio. Cualquier proyecto que vaya a tener servidores propios —y una minera los va a tener— necesita un Active Directory local. La pregunta no es si, sino dónde vive y con qué resiliencia.

Dónde viven los controladores de dominio

Alojar los controladores en un centro de datos externo tiene ventajas reales: energía, refrigeración, respaldo, monitoreo y personal de operación que un sitio en desarrollo todavía no tiene.

Tiene también una consecuencia que hay que dimensionar antes de tomar la decisión: los dispositivos con unión híbrida requieren línea de vista periódica hacia los controladores de dominio. Si el enlace hacia el sitio cae, la autenticación local se degrada y eventualmente los equipos dejan de ser utilizables.

Con el proyecto en fase administrativa, eso es una molestia. Con la planta operando —turnos, báscula, laboratorio, control de acceso, despacho— es un evento de producción.

Es exactamente el tipo de decisión que hay que tomar antes: colocar un controlador de dominio en sitio cuesta poco mientras se está construyendo la red y cuesta mucho cuando ya hay operación que interrumpir. Un controlador local, incluso de solo lectura, mantiene la autenticación viva cuando el enlace no está.

Lo que nos enseñó el único incidente en dos años

En un entorno de este tipo que operamos desde hace dos años, con toda la infraestructura del proyecto en nuestro centro de datos, hemos tenido un solo incidente: dos horas de interrupción por una falla del enlace dedicado.

No fue una falla de servidores, ni de almacenamiento, ni de respaldos. Fue el enlace.

Eso confirma dos cosas. La primera, que el modo de falla dominante en este tipo de arquitectura es la conectividad, no el cómputo. La segunda, que dimensionar la resiliencia de autenticación en sitio no es un ejercicio teórico: es la respuesta al único problema que realmente se presentó.

2. Cuándo no conviene activar el failover

Este punto merece su sección propia porque casi todo el mundo habla de tener redundancia y casi nadie habla de cuándo usarla. ¿Conmutas en cuanto se cae el principal, o te esperas? Casi nadie tiene esa respuesta por escrito, y entonces se decide en caliente.

Durante ese incidente teníamos el failover disponible. No lo activamos.

El razonamiento fue de costo-beneficio, evaluado en caliente:

• La conmutación tenía un costo propio de esfuerzo y de riesgo: la maniobra en sí, el comportamiento del roll-back al enlace principal, y la posibilidad de dejar sesiones o replicación en estado inconsistente.
• El proveedor tenía un SLA comprometido y un tiempo de resolución estimado dentro de ese margen.
• El impacto real, en fase preproducción, no detenía ninguna operación crítica.

Con esos tres elementos, apegarse al SLA del carrier y esperar era la decisión correcta. Conmutar por reflejo habría implicado más trabajo y más riesgo que el problema que resolvía.

Tener redundancia y activarla son decisiones distintas. La conmutación no es gratuita, y ejecutarla automáticamente ante cualquier interrupción puede salir más caro que la interrupción misma.

Ahora bien: ese mismo cálculo da un resultado diferente cuando hay planta operando. El umbral de activación baja, porque el costo de la espera sube. Y ahí está otra vez el criterio de fondo — definir por escrito los umbrales antes del arranque, no con la planta detenida:

• Qué escenario dispara conmutación automática, sin consulta.
• Cuál queda a criterio del operador, y con qué información decide.
• Cuál se apega al SLA del proveedor y simplemente se espera.

Escribir esa tabla cuesta una tarde. Improvisarla durante un paro cuesta bastante más.

3. La base de datos de la que depende cuánto vale el proyecto

Una minera en desarrollo tiene un activo de información que no se parece a nada del entorno administrativo: la base de datos geocientífica.

Barrenación, muestreo, ensayes, geotecnia, topografía. De ahí salen las estimaciones de recurso, los estudios de factibilidad y el reporteo con el que se busca financiamiento. En términos prácticos, es el dato del que depende la valuación de la empresa.

Eso impone requisitos distintos a los del correo y los archivos de oficina:

• Disponibilidad ligada a campaña. Durante una campaña de barrenación, la captura y validación no pueden esperar; el costo de tener equipos y personal detenidos en campo es alto.
• Integridad y trazabilidad. Es información auditable: importa quién capturó qué y cuándo, y que el histórico no se pueda alterar en silencio.
• Sincronización desde campo. La captura ocurre en sitios sin conectividad estable, con reconciliación posterior.
• Confidencialidad de nivel distinto. En un proyecto preproducción, la información geológica es sensible a la valuación. No se trata como un recurso administrativo más.

Traducido: esta plataforma no se dimensiona con el mismo criterio que el correo y los archivos de oficina. Es la carga que define la arquitectura, no la que se acomoda a ella.

4. Dos copias que resuelven dos problemas distintos

El error más común en esta etapa es tratar el respaldo como una sola cosa. No lo es. Hay dos amenazas distintas y cada una necesita su propia respuesta.

Borrado malicioso. Un atacante con credenciales administrativas no cifra y se va: primero destruye los respaldos. Contra esto la respuesta es inmutabilidad: un repositorio donde los puntos de restauración no pueden borrarse ni modificarse durante un periodo definido, ni siquiera con credenciales válidas. Un repositorio endurecido sobre hardware dedicado, con acceso administrativo restringido y sin exposición a la red de producción, es la implementación que efectivamente cumple esa promesa. Un recurso compartido en red al que se le llama "inmutable" no lo es.

Pérdida de sitio. Incendio, inundación, corte prolongado, pérdida física de las instalaciones. Contra esto la respuesta es una copia fuera de sitio, en un dominio de falla distinto.

Son problemas diferentes y no se cubren mutuamente. La regla de respaldo vigente pide al menos una copia inmutable y al menos una fuera de sitio — no exige que la misma copia cumpla las dos funciones, pero sí que ambas estén cubiertas.

Y dos cosas que se pasan por alto casi siempre:

• El dominio de falla compartido. Si el plano de identidad, los datos y los respaldos viven en el mismo sitio, un solo evento le quita a la empresa el acceso, la autenticación y el medio de recuperación al mismo tiempo.
• La recuperación del directorio. Restaurar controladores de dominio no es restaurar máquinas virtuales. Es un procedimiento con orden, aislamiento y limpieza de metadatos, y es el único que no se puede improvisar cuando cientos de usuarios están detenidos. Tener respaldo no es lo mismo que poder recuperar: el procedimiento se prueba en laboratorio, no en el incidente.

5. OT antes de que llegue el integrador de planta

Este es el punto donde la ventana se cierra más rápido, y el que con más frecuencia se decide por omisión.

Cuando arranca la construcción de planta, llegan los sistemas de control: PLCs, SCADA, historiadores, instrumentación, básculas, laboratorio. Llegan con su propio integrador, con su propio calendario y con la prioridad de poner la planta en marcha. Si nadie definió antes cómo se relaciona esa red con la red corporativa, la decisión la toma el instalador — y casi siempre en favor de lo que sea más rápido de comisionar.

Las decisiones que hay que tomar mientras todavía son diseño:

• Separación entre la red de proceso y la corporativa, con la segmentación definida antes del cableado.
• Identidad: si los sistemas de control van a autenticar contra el directorio corporativo o van a tener su propio esquema. Que el control de proceso dependa de un directorio remoto, al otro lado de un enlace, es un acoplamiento que después nadie quiere desarmar.
• Visibilidad desde el inicio: el monitoreo pasivo del tráfico industrial instalado durante el comisionamiento cuesta una fracción de lo que cuesta introducirlo en una planta operando, donde cualquier intervención compite contra la producción.

Hacer esto en greenfield es incomparablemente más barato que retrofitear. Es, probablemente, el ejemplo más claro del criterio de este artículo.

6. Qué se terceriza cuando no hay equipo

Sin un equipo de TI completo, la pregunta no es si se terceriza, sino qué.

Una separación que funciona en esta etapa:

Se terceriza lo que exige operación continua o especialización profunda: monitoreo y operación 24×7, respaldo y recuperación, seguridad, administración de plataforma.

Se conserva internamente lo que exige contexto del negocio: relación con las áreas operativas, definición de requisitos, gestión de proveedores, y las decisiones de arquitectura —que se toman con asesoría, pero no se delegan.

Y hay una condición que suele olvidarse: la operación tiene que quedar documentada del lado del cliente, no solo del proveedor. Un proyecto en el que toda la memoria técnica vive en un tercero es un proyecto con un riesgo de dependencia que ninguna auditoría va a aprobar cuando la empresa madure.

7. La curva: qué antes del arranque y qué puede esperar

Ordenado por lo que cuesta hacerlo después. Si vas a pelear presupuesto, pelea por lo de arriba.

Antes del arranque, sin excepción:

• Modelo de identidad y ubicación de los controladores de dominio, con resiliencia en sitio.
• Arquitectura de respaldo con las dos funciones cubiertas, y el procedimiento de recuperación probado.
• Segmentación IT/OT definida en el diseño.
• Umbrales de conmutación y escalamiento por escrito.
• Dimensionamiento de la plataforma geocientífica según sus propios requisitos.

Puede esperar, y conviene que espere hasta tener demanda real:

• Herramientas de productividad más allá de lo básico.
• Automatización de procesos administrativos.
• Portales internos, tableros, integraciones de conveniencia.
• Crecimiento de licenciamiento por encima del uso comprobado.

El error frecuente es invertir el orden: resolver primero lo visible —lo que el usuario percibe— y dejar identidad, respaldo y segmentación para "cuando haya tiempo". Cuando hay tiempo, ya hay planta operando, y entonces cada una de esas decisiones cuesta un múltiplo de lo que costaba antes.

Un proyecto minero en desarrollo no necesita, en esta etapa, un área de TI grande. Necesita que las tres o cuatro decisiones irreversibles se tomen bien y a tiempo, y que la operación diaria esté cubierta por alguien que conteste el teléfono a las 3 de la mañana.

Todo lo demás se construye después, cuando haya producción, presupuesto recurrente y una estructura que lo sostenga. Y ahí es donde entramos nosotros en proyectos en esta etapa: sostener la operación diaria mientras la superintendencia pelea las decisiones que de verdad no se pueden delegar.

Porque identidad, respaldo y separación de redes no se construyen después. Se heredan.