← Volver al blog Gobierno de TI

Políticas de tecnología: cuáles necesitas de verdad

Una política de tecnología es una regla escrita que dice qué se puede hacer, qué no, quién autoriza las excepciones y qué pasa si se incumple. Si a un documento le quitas cualquiera de esas cuatro partes, deja de ser una política y se convierte en una recomendación: se lee una vez, se archiva y no cambia la conducta de nadie.

Esta guía responde lo que casi nunca se responde: cuáles son las ocho políticas que de verdad necesita una empresa mexicana y cuáles se venden de más, cómo se redacta una que sea exigible ante recursos humanos, cómo se publica y se acusa de recibo para que tenga efecto, con qué frecuencia se revisa, y los siete errores que hacen que un manual completo de políticas no proteja de nada.

Qué es una política de tecnología y qué la hace exigible

La confusión de base es tratar como sinónimos tres documentos que hacen cosas distintas y se escriben distinto:

Y hay una segunda condición, que es la que separa una política real de un texto bonito: tiene que ser exigible. Una regla se puede hacer valer cuando reúne cuatro cosas: está escrita en términos que describen conductas observables, se comunicó de forma demostrable, dice qué consecuencia tiene incumplirla, y la empresa la aplica igual a todos. Si falta la comunicación demostrable —el acuse—, la política existe para el auditor y no existe para el área jurídica.

Cuándo hace falta escribirlas y cuándo es papel

No toda empresa necesita un cuerpo de políticas de tecnología hoy. Distinguir el caso ahorra meses.

Cinco señales de que sí

1. Hay personas con acceso a datos de terceros. Padrones de clientes, expedientes de empleados, información de pacientes o de menores. En el momento en que la empresa trata datos personales de otros, las reglas de acceso dejan de ser higiene y pasan a ser obligación.
2. Alguien ya usó una herramienta de IA con información de un cliente. Ocurre antes de que la empresa se entere, y sin una regla escrita no hay nada que reclamar.
3. Trabajo remoto o híbrido con equipo propio del empleado. En cuanto el equipo de trabajo deja la oficina, quién responde por la información que contiene deja de ser obvio.
4. Un cliente empezó a mandar cuestionarios de proveedor. Los formularios de cadena de suministro preguntan por políticas nombradas, fechas de última revisión y responsables. Sin ellas, la empresa no pasa el filtro documental.
5. Hubo una salida conflictiva. Si alguien se fue y nadie sabía qué accesos tenía, la política que hacía falta era la de altas, bajas y cambios, y hacía falta antes.

Tres señales de que todavía no

1. Quieres el manual para una carpeta. Treinta políticas descargadas y adaptadas con buscar-y-reemplazar producen un documento que no describe tu operación y que nadie va a poder aplicar.
2. No hay quien autorice excepciones. Si no está definido quién puede decir «esta vez sí», la primera excepción legítima derogará la regla en silencio.
3. El equipo entero cabe en una mesa y toda compra pasa por el dueño. Ahí lo urgente son los respaldos y el control de accesos, no el cuerpo normativo.

Las 8 políticas mínimas, y en qué orden se escriben

El orden no es alfabético ni por importancia teórica: es por riesgo desatendido. Las tres primeras cubren la mayor parte de lo que sale mal.

1. Accesos: altas, bajas y cambios

Quién solicita un acceso, quién lo autoriza, quién lo crea y —lo que casi siempre falta— quién lo revoca el mismo día de la baja. Debe incluir una revisión periódica de quién tiene qué, porque los accesos se acumulan: la gente cambia de puesto y conserva los permisos del anterior. Es la política que más incidentes evita y la que menos se escribe.

2. Respaldo y recuperación

Qué se respalda, cada cuánto, dónde queda la copia, cuánto tiempo se conserva y —el punto que la convierte en útil— cada cuánto se prueba una restauración completa y quién firma que funcionó. Un respaldo que nunca se restauró no es un respaldo: es un archivo de tamaño tranquilizador.

3. Uso aceptable de equipos y cuentas

Qué es uso legítimo del equipo y las cuentas corporativas, qué queda prohibido, qué expectativa de privacidad tiene la persona sobre el correo y los dispositivos de la empresa, y qué se monitorea. Esta es la política que tiene que redactarse con el área laboral: es la que sostiene una consecuencia si algún día hace falta.

4. Clasificación y manejo de la información

Tres o cuatro niveles bastan —pública, interna, confidencial, restringida— y cada nivel dice tres cosas: quién puede verla, cómo se comparte fuera y cuándo se destruye. Sin clasificación, las demás políticas no tienen a qué aplicarse: «protege la información sensible» no es exigible si nadie definió cuál lo es.

5. Adquisición de software y servicios en la nube

La regla que corta el shadow IT: ningún servicio que vaya a almacenar datos de clientes, de empleados o información financiera se contrata sin revisión previa y sin quedar registrado, sin importar su costo mensual. El umbral no puede ser el precio, porque el daño no depende del precio.

6. Dispositivos personales y trabajo remoto

Qué se permite hacer desde un equipo que no es de la empresa, qué controles mínimos exige (bloqueo, cifrado, actualizaciones, segundo factor), qué pasa al terminar la relación laboral y cómo se borra la información corporativa sin tocar la personal. En México, además, el trabajo a distancia tiene obligaciones laborales propias sobre equipo y condiciones que esta política debe reconocer.

7. Uso de inteligencia artificial generativa

La más nueva y la que ya se está incumpliendo. Define qué información puede salir de la organización hacia un modelo de terceros, qué usos quedan prohibidos —decisiones sobre personas, contenido que se publica sin revisión, código que toca sistemas de producción—, qué herramientas están autorizadas y quién revisa una nueva. Lo desarrollamos en políticas de uso responsable de IA.

8. Respuesta a incidentes

A quién se avisa, en cuánto tiempo, quién decide si se apaga un sistema, quién habla con el cliente y quién con la autoridad. Cabe en dos páginas y es la que se busca a las tres de la mañana; por eso tiene que tener teléfonos, no puestos.

Las que se venden de más

Los paquetes comerciales de políticas suelen traer entre veinticinco y cuarenta documentos. La mayoría de las empresas medianas no puede mantener esa cantidad, y mantener es la parte cara: cada política hay que revisarla, versionarla, volver a comunicar y volver a acusar. Cuatro que casi siempre sobran al inicio:

• Política de desarrollo seguro, en empresas que no desarrollan software. Si todo el software es de terceros, lo que hace falta es la política de adquisición, no la de desarrollo.
• Política de centro de datos, en empresas cuya infraestructura entera está en la nube. Lo aplicable es la gestión del proveedor.
• Políticas separadas para cada tecnología. Una política de correo, otra de mensajería, otra de videoconferencia y otra de almacenamiento son, casi siempre, la misma política de uso aceptable escrita cuatro veces y desactualizada en tres.
• Política de continuidad del negocio, antes de tener respaldos probados. Es un documento excelente y es el segundo paso, no el primero.

La regla práctica: se escribe una política cuando su ausencia ya causó un problema, cuando alguien de fuera la exige o cuando protege información de terceros. Escribir por completitud produce cuerpos normativos que nadie lee y que hay que sostener para siempre.

Anatomía de una política: las 9 secciones

Toda política de tecnología, sin importar el tema, se escribe con las mismas nueve secciones. Si una falta, se sabe cuál va a ser el problema.

1. Objetivo — qué se quiere evitar, en una frase. No «regular el uso de la tecnología», sino «evitar que información de clientes salga a servicios no autorizados».
2. Alcance — a quién aplica y a qué no. Incluye explícitamente a terceros, becarios y contratistas, que es justo donde se cuela la excepción.
3. Definiciones — solo los términos que después se usan como criterio. Si una definición no se usa en ninguna regla, sobra.
4. Roles y responsabilidades — quién cumple, quién vigila y quién autoriza excepciones. Con puestos, no con nombres de personas.
5. Reglas — el cuerpo. Redactadas en conductas observables: «se hace», «no se hace», «se requiere autorización de». Las palabras que matan una política son «adecuado», «razonable», «cuando sea posible» y «se procurará».
6. Excepciones — cómo se pide una, quién la autoriza, qué control compensatorio exige y en qué fecha caduca. Una excepción sin caducidad deroga la regla.
7. Consecuencias del incumplimiento — redactadas con el área laboral y coherentes con el reglamento interior de trabajo. Sin esta sección no hay nada que sostener.
8. Vigencia y revisión — desde cuándo aplica y cada cuánto se revisa. Anual es el estándar razonable; semestral, si la tecnología del tema cambia rápido.
9. Control de versiones y aprobación — código del documento, versión, fecha, quién la elaboró, quién la revisó y quién la aprobó. Es lo primero que pide un auditor y lo último que se escribe.

Lo que el marco legal mexicano obliga a contemplar

No es asesoría jurídica, y cada caso concreto se revisa con el área legal de la empresa. Pero hay cuatro frentes que en México condicionan cómo se redactan estas políticas, y omitirlos es el origen de la mayoría de los documentos que no sirven cuando hacen falta:

• Protección de datos personales. La legislación mexicana en materia de datos personales en posesión de particulares exige, entre otras cosas, un aviso de privacidad, un responsable identificable, medidas de seguridad proporcionales y la atención de los derechos de acceso, rectificación, cancelación y oposición. En términos de políticas, eso se traduce en tres obligaciones concretas: clasificar la información, controlar quién accede a datos personales y tener un procedimiento de respuesta a incidentes que contemple la notificación.
• Trabajo a distancia. El teletrabajo tiene en México regulación propia sobre el equipo de trabajo, las condiciones y la reversibilidad del esquema. La política de dispositivos y trabajo remoto tiene que ser coherente con lo que la empresa haya pactado en materia laboral, o se contradicen entre sí.
• Conservación de información fiscal y contable. La obligación de conservar la contabilidad —cinco años como referencia general— condiciona la política de respaldo: los periodos de retención no se eligen por comodidad de almacenamiento.
• Facturación electrónica. Cualquier herramienta que emita o resguarde comprobantes fiscales digitales queda dentro del alcance de las políticas de acceso y respaldo, aunque sea un servicio contratado a un tercero.

Una advertencia de redacción: no conviene citar números de artículo dentro de una política. Las leyes se reforman, el documento queda desactualizado y el error se propaga a todas las copias. Se cita el ordenamiento por su nombre y, si hace falta el detalle, va en un anexo que se actualiza solo.

Publicar, acusar de recibo y hacerlas valer

Esta es la parte que se salta y es la que decide si la política sirve. Cuatro pasos, en este orden:

1. Aprobación con fecha y firma. La aprueba quien tiene la facultad —dirección general o el foro de gobierno—, no el área que la redactó. Queda versión, fecha y aprobador.
2. Publicación en un solo lugar. Una carpeta o un portal que sea el único sitio donde vive la versión vigente. Si circula por correo, en seis meses hay cuatro versiones distintas conviviendo.
3. Acuse de recibo por persona. Con nombre, fecha y versión. Es lo único que convierte «debiste saberlo» en un hecho demostrable, y es lo que se pide cuando hay que sostener una consecuencia.
4. Inducción y recordatorio. Al ingresar y al cambiar la versión. Las políticas de uso aceptable y de IA generativa conviene reforzarlas al menos una vez al año, porque son las que más cambian de contexto.

Y una quinta, la que casi nadie hace: medir el cumplimiento con algo que no sea el acuse. Por ejemplo, contar cuántos accesos siguen activos de personas que ya no trabajan en la empresa, o cuántos servicios en la nube aparecen en el estado de cuenta y no en el registro de proveedores. Esos dos números dicen más sobre el estado real de las políticas que cualquier auditoría documental.

7 errores que las vuelven papel mojado

1. Redactar con adjetivos en vez de conductas. «Uso adecuado», «medidas razonables», «cuando sea posible». Cada palabra de esas es una excepción que nadie tuvo que pedir.
2. Copiar un paquete y cambiarle el nombre. Se nota de inmediato: áreas que no existen, roles que la empresa no tiene, códigos de documento ajenos en los pies de página. Además del ridículo ante el auditor, la política no describe tu operación.
3. Escribir la de uso aceptable sin el área laboral. Es la que puede terminar sosteniendo una sanción. Redactada solo por sistemas, no se puede aplicar.
4. Prohibir sin dar alternativa. Prohibir la mensajería personal para temas de trabajo sin habilitar un canal corporativo no elimina la conducta: la esconde. Toda prohibición útil viene acompañada de la vía legítima para hacer lo mismo.
5. No definir quién autoriza excepciones. La primera excepción legítima la resolverá quien esté disponible, y a partir de ahí la regla vale lo que la disponibilidad de esa persona.
6. Publicarlas y no volver a mirarlas. Sin fecha de revisión ni dueño, en dos años la mitad menciona herramientas que ya no se usan, y la credibilidad del conjunto cae con ellas.
7. Confundir cantidad con protección. Treinta políticas mal mantenidas protegen menos que seis vigentes, comunicadas y acusadas. Cada documento de más es mantenimiento para siempre.

Ejemplo resuelto: política de uso de IA generativa

Así se ve el cuerpo de reglas de una política corta, para una empresa de servicios de alrededor de 120 personas que usa asistentes generativos comerciales. Es un ejemplo ilustrativo; el contenido concreto depende del sector y del tipo de información que se maneje.

Seis reglas, una página, y con las secciones de excepciones, consecuencias y versiones cabe en tres. Lo que hace que funcione no es su extensión: es que cada regla describe una conducta que se puede observar y que el anexo A es una lista concreta que alguien mantiene. Si el marco de gobierno de la IA hace falta a otro nivel, está en la guía de ISO/IEC 42001.

Preguntas frecuentes

Conclusión: tres decisiones

Las políticas de tecnología sirven cuando resuelven un problema que la empresa ya tiene: accesos que nadie revoca, servicios contratados sin revisión, información de clientes saliendo a herramientas que nadie autorizó. Cuando se escriben por completitud, se convierten en un cuerpo normativo que solo existe para el auditor.

Si vas a empezar, tres decisiones ordenan el resto: escribe primero accesos, respaldo y uso aceptable y deja las demás para después; redacta cada regla en conductas observables, sin «adecuado» ni «razonable»; y no publiques ninguna sin acuse de recibo por persona, porque sin acuse la política no es exigible. Las tres se toman antes de escribir la primera línea.