En la mayoría de las empresas, la conversación sobre tecnología empieza cuando algo falla, no cuando se diseña la solución. El resultado es predecible: proveedores que prometen “transformación digital” y “soluciones integrales”, pero sobre una base que nadie entiende realmente.
El problema no es que el usuario final no sepa programar ni administrar servidores; el problema es que desconoce los conceptos mínimos necesarios para exigir lo correcto y detectar a tiempo una bomba de humo. Este artículo no busca que te conviertas en ingeniero, sino darte un marco mental sencillo para conversar con proveedores, hacer las preguntas correctas y proteger tu negocio.
1. Arquitectura, redes y seguridad: el mapa que nadie tiene
Cuando llego a una empresa, el patrón se repite: nadie tiene un diagrama actualizado de la arquitectura, casi nadie entiende cómo está segmentada la red, y menos aún cómo se controla el acceso desde fuera mediante VPN u otros mecanismos seguros. En muchos casos, ni siquiera hay claridad sobre qué servicios se están ejecutando en qué servidores, qué puertos se exponen o qué protocolos se usan para comunicar los distintos componentes.
Sin este mapa básico es imposible tomar decisiones sanas. No puedes evaluar el impacto de un cambio, no puedes dimensionar riesgos de seguridad y no puedes auditar a un proveedor que llega a “modificar algo rápido en producción”. Si tú, como cliente, no pides al menos un inventario y un diagrama de alto nivel, tu plataforma termina siendo una caja negra donde cualquier intervención es una apuesta ciega.
2. Seguridad de datos: en tránsito, en reposo y expuestos sin querer
Otra zona oscura suele ser el nivel real de seguridad de los datos. Se mezclan conceptos como “está cifrado”, “tiene SSL”, “usa HTTPS”, sin distinguir entre cifrado en tránsito, cifrado en reposo y protección efectiva de archivos que contienen datos personales o sensibles.
He visto sitios donde documentos con datos personales quedan indexados públicamente, bases de datos sin cifrado expuestas en redes mal segmentadas, o sistemas que dependen de algoritmos de cifrado obsoletos o mal configurados. La pregunta mínima que deberías hacer es: “¿Qué datos sensibles manejo, cómo se protegen en tránsito, cómo se protegen en reposo y quién puede acceder a ellos?”.
3. Ambientes de desarrollo, QA y producción: no todo es “el servidor”
Para muchos equipos, solo existe “el servidor” o “la página”. Pero una plataforma sana debería diferenciar al menos tres ambientes: desarrollo, QA (o staging) y producción. Cada uno con su finalidad, su configuración, sus datos y sus resguardos.
Cuando no hay separación clara de ambientes, las pruebas se hacen directamente en producción, los datos reales se usan para experimentar y los errores impactan al usuario final. Como cliente, no necesitas saber cómo se configura cada ambiente, pero sí debes exigir que exista al menos un entorno pre-productivo donde se prueben los cambios antes de llegar a tus usuarios.
4. IA, “vibe coding” y el espejismo de la productividad
La irrupción de asistentes de código basados en IA y del “vibe coding” ha hecho el panorama más complejo e inseguro cuando no se entiende lo que se está construyendo. Muchos desarrolladores integran fragmentos de código generados por IA sin revisar implicancias de seguridad, sin validar dependencias y sin pensar en el ciclo de vida de la solución.
Tu responsabilidad como cliente no es revisar cada línea de código, pero sí pedir criterios: “¿Cómo se valida que el código generado por IA sea seguro?”, “¿Qué lineamientos siguen para el uso de herramientas de IA en desarrollo?”, “¿Qué datos salen de la organización cuando usan estas herramientas?”. Si no hay política, solo hay improvisación.
5. Respaldos que existen… pero nadie ha probado restaurar
“Tenemos backups” es probablemente una de las frases más peligrosas en tecnología cuando no se acompaña de “y probamos periódicamente la restauración completa”. Hay varios niveles de respaldo que suelen ignorarse: configuraciones de infraestructura, código fuente, artefactos desplegados y bases de datos.
No basta con saber que “algo” se copia cada noche. Hay que saber dónde se almacenan los respaldos, cuánto tiempo se retienen, cuál es el procedimiento para restaurar una plataforma completa y cada cuánto se ensaya ese procedimiento. La experiencia muestra que muchos planes de backup fallan justo cuando se los necesita porque nadie hizo pruebas de restauración real.
6. Web, apps y APIs: tres caras de la misma plataforma
Desde la mirada del usuario final, un sitio web, una app iOS o una app Android son productos distintos. En la práctica, la mayoría de las soluciones modernas comparten una misma fuente de datos a través de APIs: servicios que exponen funciones y datos para ser consumidos por distintos canales.
Esa capa de APIs es el verdadero corazón de tu plataforma. Si no tienes visibilidad de esa capa ni de su documentación, dependes completamente del proveedor para cualquier integración o cambio. Lo mínimo que deberías exigir es: descripción de las APIs clave, esquema de autenticación, límites de uso y qué datos exactos se exponen y a quién.
7. Lo que el usuario no tiene que saber (y lo que sí debe exigir)
No es realista pedirle a un gerente, director o dueño de negocio que entienda a detalle redes, cifrado, QA o arquitecturas de microservicios. Pero sí es razonable exigir un nivel mínimo de alfabetización digital que le permita hacer las preguntas correctas y no delegar ciegamente todo en el proveedor.
Ese mínimo incluye saber que debe existir un mapa de arquitectura, una estrategia de seguridad de datos, ambientes diferenciados, políticas claras de uso de IA en desarrollo, respaldos probados y una capa de APIs bien definida. Entender lo mínimo no es capricho técnico; es la única forma de proteger tu negocio en un mercado saturado de promesas vacías.