Ilustración del ciclo de vida del hardware TI con cinco etapas IMAC-R conectadas y servidores en racks etiquetados para retiro

Ciclo de vida del hardware TI 2026: del IMAC-R al retiro

Guías Técnicas Elite Center | | 11 min lectura

TL;DR. El hardware TI no se compra y se olvida: vive cinco etapas operativas conocidas como IMAC-R (Install, Move, Add, Change, Retire) y termina su ciclo con dos obligaciones que la mayoría de las empresas chilenas todavía manejan mal: la Ley 20.920 (REP) sobre residuos electrónicos y la próxima entrada en vigor el 1 de diciembre de 2026 de la Ley 21.719 de datos personales. Un programa ITAM (IT Asset Management) bien armado reduce entre 15% y 20% el TCO de la cartera, según Gartner e IDC. Esta guía cubre las cinco etapas, los costos ocultos del hardware vencido, las obligaciones legales chilenas y la práctica concreta de sanitización de datos según NIST SP 800-88 Revisión 2, publicada en septiembre 2025.

¿Qué es IMAC-R y por qué es el marco para gestionar hardware TI?

IMAC-R es la sigla para Install, Move, Add, Change, Retire. Describe las cinco operaciones rutinarias que sufre cualquier activo de hardware durante su vida útil. La extensión IMACD agrega Disposal como sexta etapa para separar el retiro lógico de la disposición física. No es un estándar ISO ni una práctica formal de ITIL: es el lenguaje común en contratos de servicios gestionados de IT, en plantillas de proveedores como Lenovo y Park Place, y en la operación diaria de cualquier área de operaciones. Lo que importa es que cubre todas las acciones que un activo va a necesitar y permite calzar costos, SLAs y responsables a cada una.

Un programa ITAM (IT Asset Management) maduro existe para no perder el control sobre esas cinco etapas. La pregunta de fondo en cada compañía es la misma: ¿sabes con precisión cuántos servidores, switches, notebooks, teléfonos IP y discos tienes en operación, dónde están, qué versión de firmware corren y cuándo entran en EOL? Si la respuesta es vaga, el resto de las decisiones (refresh, presupuesto, seguridad, cumplimiento) trabaja con cimientos endebles.

¿Cuánto debe durar un servidor empresarial?

El estándar empresarial es 5 años de operación productiva. Los hyperscalers son la mejor referencia pública: AWS revirtió en 2025 su política de extender la vida útil a 6 años, volviendo a 5 tras detectar mayor degradación que la proyectada en aceleradores y servidores. Para una empresa promedio chilena, 5 años de uso productivo en producción y eventual extensión a 7 años en ambientes secundarios (desarrollo, pruebas, respaldo) con servidores reacondicionados certificados es una política sostenible.

El argumento financiero detrás del refresh no es la performance bruta: es el riesgo. Los datos de IDC citados por Juriba muestran que el downtime no planificado promedio anual sube de 2,6 horas en servidores menores a 3 años a 5,1 horas en servidores con más de 5 años. Cuando se valoriza una hora de downtime —que Gartner estimó en USD 9.000 por minuto en 2024 para empresas con dependencia digital intensa— la ecuación se invierte rápido. La pregunta no es si el equipo “todavía funciona”, es cuánto cuesta el rato que no funciona y si la organización puede absorberlo.

Downtime promedio anual por edad del servidorServidores menores a 3 años promedian 2,6 horas anuales de downtime no planificado, los de 3 a 5 años unas 3,5 horas y los mayores a 5 años llegan a 5,1 horas según IDC.Downtime no planificado por edad del servidorHoras anuales promedio — IDC01,53,04,56,02,6< 3 años3,53-5 años5,1> 5 añosFuente: IDC, vía Juriba (2024)

Para servidores en ambientes no productivos (desarrollo, testing, laboratorio, replicación de respaldo), un equipo Dell 14G/15G o HPE Gen10/Gen10+ reacondicionado y certificado, como los que ofrece Reborn by Elite Center, permite extender el ciclo a 7 años con TCO favorable. La política sana es separar fleet productivo de fleet secundario y aplicar refresh diferenciado.

¿Cuáles son las cinco etapas IMAC-R en operación?

EtapaAcciónPregunta operativaRiesgo si se descuida
InstallRecepción, configuración inicial, alta en CMDB y baseline de seguridad¿Está el equipo registrado, parchado y con su línea base de configuración?Activo invisible al área de seguridad; configuraciones por defecto
MoveCambio físico o lógico de ubicación, segmento de red o sitio¿Sabes en qué sitio y rack está cada activo hoy?Inventario desfasado; pérdida de cobertura de soporte
AddAmpliaciones de capacidad: RAM, disco, NIC, GPU, licencia¿La modificación queda documentada en CMDB y auditable?Capacidad no aprovechada; auditorías de licencia con sorpresas
ChangeModificaciones funcionales: firmware, OS, virtualización, cambios de propósito¿Existe un proceso de change management aprobando el cambio?Cambios no controlados; incidentes con causa raíz difusa
RetireSalida de operación productiva, reasignación o disposición¿El activo fue sanitizado, etiquetado y entregado a gestor REP?Datos personales en hardware sin trazabilidad; multas y reputación

Cada etapa debería tener un dueño de proceso (típicamente IT Operations o un MSP), un SLA definido y un registro auditable. Cuando estos cinco procesos viven en hojas de cálculo personales, el primer síntoma es discrepancia entre lo que la CMDB dice tener y lo que realmente hay en el rack. El segundo síntoma son hallazgos en auditoría: equipos con licencias no renovadas, equipos con firmware vulnerable, o equipos retirados sin certificado de destrucción de datos.

¿Qué exige la Ley REP en Chile para el hardware TI?

La Ley 20.920 marco para la gestión de residuos, conocida como Ley REP (Responsabilidad Extendida del Productor), declara los Aparatos Eléctricos y Electrónicos (AEE) como uno de los siete productos prioritarios. La obligación principal recae en productores e importadores, que deben adherir a un Sistema de Gestión y financiar la recolección y valorización. Para una empresa usuaria, la obligación operativa concreta es entregar el hardware retirado a un gestor autorizado registrado y obtener trazabilidad documental del proceso, según lineamientos del Ministerio del Medio Ambiente.

El contexto chileno es relevante. Según reportes de País Circular, Chile genera del orden de 215.000 toneladas de residuos electrónicos al año (cerca de 10 kg por persona) y la tasa de reciclaje formal está bajo 5%. Globalmente, el Global E-waste Monitor 2024 de UNITAR/UIT documentó 62 mil millones de kilos generados en 2022 con apenas 22,3% recolectado formalmente. La expectativa pública sobre las empresas que retiran hardware no va a aflojar: la trazabilidad de la disposición es un control que aparecerá cada vez más en proveedores, clientes y aseguradoras.

¿Cómo se cumple con la Ley 21.719 al retirar discos y servidores?

La Ley 21.719 de protección de datos personales, publicada el 13 de diciembre de 2024 y con plena entrada en vigor el 1 de diciembre de 2026, redefine la línea base de gestión de datos en Chile. La eliminación es una de las acciones más frecuentes y peor documentadas: cuando un servidor sale de producción, los discos y SSD pueden contener datos personales identificables, registros financieros, correo histórico, copias de bases de RR.HH. o información clínica. Eliminar bien es obligatorio, no opcional.

El estándar internacional para hacerlo es NIST SP 800-88 Revisión 2, publicada en septiembre 2025. Define tres niveles operativos según el riesgo y el destino del soporte:

  • Clear: sobrescritura mediante herramientas estándar. Adecuado cuando el soporte se reasigna dentro de la organización. No protege contra atacantes con recursos avanzados de laboratorio.
  • Purge: sanitización criptográfica (Cryptographic Erase, CE) o desmagnetización para medios magnéticos. Dejar el soporte sin posibilidad práctica de recuperar datos, manteniendo el medio operativo.
  • Destroy: destrucción física del soporte (trituración, incineración). Único método para soportes con datos altamente sensibles que salen de la organización sin reutilización.

La práctica recomendada es definir una matriz de decisión por tipo de dato y destino del soporte. Por ejemplo: SSDs con datos clínicos que salen a un programa de donación deben ir a Destroy. HDDs de servidores reasignados a desarrollo interno pueden ir a Clear o Purge. La organización siempre debe quedar con un certificado de sanitización o destrucción firmado por el gestor.

¿Qué ahorro real entrega un programa ITAM bien implementado?

Gartner publica que el 40% al 60% del presupuesto de IT Operations se va en mantener activos (hardware y software). En esa base, un programa ITAM maduro entrega entre 15% y 20% de reducción del TCO de la cartera, según referencias de Gartner e IDC. Los ejes del ahorro son tres y se pueden gobernar en simultáneo.

  1. Optimización de licencias y contratos: dejar de pagar soporte premium por equipos retirados, consolidar licencias por uso real, evitar renovaciones automáticas sobre flotas que ya no existen.
  2. Refresh basado en datos: decidir el reemplazo de un servidor o un parque de notebooks con telemetría real de fallos, downtime y consumo, no con sensación de obsolescencia.
  3. Reducción del shadow inventory: identificar y dar de baja equipos que pagan energía, espacio en datacenter y póliza sin generar valor productivo.

Gartner también señala que un ITAM bien implementado se cruza con la operación de continuidad operacional: saber dónde están los activos críticos, su edad, su estado y su contrato de soporte es prerrequisito para un BCP creíble. Sin inventario vivo, el plan de continuidad opera sobre supuestos.

¿Qué herramientas y procesos necesita un programa ITAM en 2026?

El stack mínimo combina cuatro componentes. Una CMDB o herramienta ITAM central, ya sea de la familia ITSM (ServiceNow, Jira Service Management) o un ITAM dedicado (Lansweeper, Snipe-IT, Device42). Un agente de descubrimiento que escanee la red y reconcilie con CMDB para detectar shadow inventory. Un proceso de cambio integrado con ITSM, donde toda operación IMAC-R se levanta como ticket aprobado, con dueño y trazabilidad. Y una política de retiro y sanitización documentada, con matriz de decisión NIST 800-88, gestor REP autorizado y archivo de certificados.

Sobre ese piso, las prácticas que distinguen a un programa maduro son: integración con compras (toda OC genera registro CMDB en alta), integración con seguridad (los activos en EOL aparecen en el inventario de vulnerabilidades sin retraso), revisión trimestral de licencias y contratos de soporte, y reporte ejecutivo mensual con métricas de utilización, antigüedad media, tasa de reasignación y costo de la cartera.

El enfoque debe ser progresivo. La trampa es comprar la herramienta y no operar el proceso. Mejor empezar por sanear el inventario actual (descubrimiento + reconciliación), definir el dueño de procesos, escribir las cinco rutinas IMAC-R como SOPs, y solo después optimizar. La mayoría de las organizaciones chilenas que invierten en herramientas sin ese trabajo previo terminan con CMDBs llenas de basura: tienen el sistema, pero no la verdad operativa que justifica tenerlo.

Conclusión: ciclo de vida como decisión financiera y de cumplimiento

Ignorar el ciclo de vida del hardware no es ahorrar: es postergar costos que aparecen como downtime, multas REP, hallazgos de auditoría bajo Ley 21.719 y deuda técnica acumulada. El marco IMAC-R organiza el trabajo en cinco etapas auditables. La Ley 20.920 y la Ley 21.719 marcan la frontera de cumplimiento, y NIST SP 800-88 Rev. 2 entrega el estándar técnico para sanitizar datos. Un programa ITAM bien armado paga su costo con 15% a 20% de reducción del TCO de la cartera.

En Elite Center asesoramos en política de refresh, gestión de servidores nuevos y reacondicionados certificados con Reborn y diseño de procesos IMAC-R alineados a NIST 800-88 y Ley REP. Si tu empresa quiere salir de la operación basada en planillas y ordenar su parque de hardware, conversemos.

⚡ ¿Necesitas infraestructura para tu empresa?