Por Dino Etcheverry, CEO – Analista de datos y Arquitectura Blockchain en Fidestamp
La seguridad se ha convertido en una condición estructural para la viabilidad de cualquier plataforma digital. Sin embargo, en muchos proyectos tecnológicos sigue abordándose como una capa adicional que se incorpora cuando el producto ya está desarrollado, aparecen los primeros clientes o se detectan vulnerabilidades. Este enfoque resulta especialmente problemático en las plataformas descentralizadas y colaborativas, donde la gestión de identidades, los permisos, el intercambio de información y la coordinación entre participantes forman parte del funcionamiento esencial del negocio.
A diferencia de las aplicaciones tradicionales, estos sistemas distribuyen funciones, datos o capacidad de decisión entre múltiples actores. La descentralización puede reducir determinadas dependencias, mejorar la trazabilidad y facilitar nuevos modelos de colaboración, pero también introduce riesgos específicos. Una clave comprometida, un contrato inteligente defectuoso o una integración externa vulnerable pueden afectar a usuarios y organizaciones que operan en entornos distintos.
En este contexto, la seguridad por diseño (security by design) propone integrar los controles de protección desde la concepción del producto. Para una startup, no significa construir una infraestructura excesivamente compleja ni invertir desde el primer día en todas las herramientas disponibles. Significa tomar decisiones arquitectónicas que permitan proteger los activos importantes, reducir la exposición al riesgo y crecer sin tener que reconstruir continuamente el sistema.
La cuestión estratégica es sencilla: ¿cómo puede una startup incorporar la seguridad a su modelo de negocio desde el principio sin ralentizar su desarrollo?
De la seguridad reactiva a la seguridad por diseño
La seguridad por diseño parte de una premisa: las decisiones iniciales condicionan la capacidad de un sistema para resistir ataques, contener incidentes y recuperarse de los fallos. La gestión de identidades, la asignación de permisos, el almacenamiento de información y los mecanismos de actualización determinan tanto el nivel de exposición como el coste de corregir problemas en el futuro.
En una plataforma descentralizada pueden intervenir usuarios, proveedores tecnológicos, nodos independientes, aplicaciones externas, contratos inteligentes y servicios de identidad. Cada participante introduce dependencias que deben analizarse antes de poner el producto en producción.
Imaginemos una startup que desarrolla una plataforma para conectar empresas con proveedores sostenibles. Su propuesta de valor consiste en verificar certificaciones ambientales, facilitar el intercambio de documentación y permitir que los compradores comprueben determinadas evidencias sobre sus proveedores.
Si la empresa desarrolla primero todas las funcionalidades y deja la seguridad para el final, podría descubrir que cualquier proveedor registrado puede modificar información que debería estar reservada a un auditor. También podría comprobar que los documentos confidenciales están accesibles mediante enlaces públicos o que una cuenta comprometida permite alterar registros relevantes.
Corregir estos problemas después del lanzamiento puede implicar modificar la arquitectura, interrumpir el servicio y asumir costes de reputación. Si, por el contrario, la startup define desde el inicio quién puede registrar información, quién puede validarla y quién puede consultarla, la seguridad pasa a formar parte del diseño funcional del producto.
La diferencia no está necesariamente en utilizar más tecnología, sino en tomar mejores decisiones antes de escribir la primera línea de código.
Cómo aplicar la seguridad por diseño en una startup
La aplicación práctica comienza por identificar qué necesita proteger la empresa y qué consecuencias tendría una vulneración. No todos los datos ni todas las operaciones tienen el mismo valor. Una startup debe priorizar en función de su actividad, los activos que gestiona y las obligaciones que asume frente a sus clientes.
Primer ejemplo: una startup de trazabilidad para cadenas de suministro.
Supongamos que una empresa tecnológica desarrolla una plataforma para registrar el recorrido de materias primas desde el productor hasta el fabricante. Los participantes pueden incorporar datos sobre el origen, las condiciones de transporte, las certificaciones y las entregas.
La propuesta comercial es ofrecer a los compradores una trazabilidad más fiable y facilitar las auditorías. Sin embargo, el registro digital solo aporta valor si existe un control razonable sobre quién introduce los datos y cómo se comprueba su validez.
La startup puede aplicar seguridad por diseño estableciendo permisos diferenciados para productores, transportistas, fabricantes y auditores. Cada participante accede únicamente a las funciones necesarias para su actividad. Las modificaciones relevantes quedan registradas y las evidencias documentales se someten a controles antes de utilizarse en una certificación.
Si incorpora blockchain, puede registrar huellas criptográficas de documentos y eventos para facilitar la comprobación posterior de su integridad. Los documentos completos, especialmente cuando contienen información comercial confidencial o datos personales, pueden mantenerse fuera de la cadena y protegerse mediante controles de acceso.
¿Qué obtiene la startup? Una plataforma que ofrece más garantías a sus clientes sin necesidad de exponer toda la información de la cadena de suministro. La seguridad no es una funcionalidad aislada: refuerza la propuesta de valor y puede convertirse en un argumento comercial para vender a fabricantes, distribuidores y empresas que necesitan demostrar la trazabilidad de sus operaciones.
Es importante, no obstante, distinguir entre integridad y veracidad. Un registro inmutable puede demostrar que un dato no se ha modificado desde que se incorporó, pero no garantiza que la información original fuera correcta. La validación de las evidencias sigue siendo imprescindible.
Segundo ejemplo: una startup que desarrolla un mercado de servicios mediante contratos inteligentes.
Imaginemos una plataforma que conecta empresas con profesionales especializados y permite gestionar pagos cuando se cumplen determinadas condiciones contractuales. La startup decide utilizar contratos inteligentes para automatizar parte del proceso.
Antes del lanzamiento, debe analizar qué sucede si un usuario introduce información incorrecta, un servicio externo deja de funcionar o una de las partes intenta aprovecharse de una condición ambigua del contrato. También debe determinar qué operaciones pueden revertirse y cuáles podrían resultar irreversibles.
La seguridad por diseño implica definir límites operativos, probar escenarios adversos y revisar el contrato inteligente antes de gestionar fondos reales. También puede requerir mecanismos de pausa para situaciones de emergencia, siempre que estén diseñados con controles que eviten abusos por parte de quienes administran la plataforma.
La gestión de claves merece una atención especial. Si una única clave permite modificar parámetros críticos o controlar fondos, su compromiso puede tener consecuencias desproporcionadas. Según el riesgo, la startup podría establecer firmas múltiples, separar las funciones administrativas y utilizar procedimientos de recuperación previamente definidos.
Desde el punto de vista empresarial, estas decisiones reducen la probabilidad de que un fallo técnico se transforme en una crisis financiera o reputacional. También facilitan explicar a clientes e inversores qué controles existen y qué riesgos siguen presentes.
Tercer ejemplo: una startup que ofrece credenciales verificables para empresas sostenibles.
Una empresa tecnológica quiere desarrollar un servicio para que las organizaciones compartan evidencias sobre sus certificaciones, políticas ambientales o auditorías. En lugar de enviar repetidamente documentos completos, una empresa podría presentar credenciales verificables ante diferentes clientes.
La arquitectura debe contemplar desde el inicio quién emite cada credencial, cómo se comprueba su autenticidad y qué sucede cuando caduca, se revoca o deja de ser válida. También debe evitar que la información compartida permita revelar más datos de los necesarios.
La startup puede diseñar un sistema en el que las organizaciones controlen qué credenciales presentan y los destinatarios puedan verificar su procedencia. Los permisos y los mecanismos de revocación deben estar definidos desde el principio, igual que la protección de las claves utilizadas para emitir o validar las credenciales.
El resultado es un servicio que puede reducir tareas administrativas y facilitar las comprobaciones entre empresas. En este modelo, la seguridad y la privacidad no son costes secundarios: constituyen parte del producto que el cliente está comprando.
Una hoja de ruta realista para los primeros meses
Una startup no necesita resolver todos los escenarios posibles antes de validar su propuesta de valor. Necesita identificar los riesgos que podrían comprometer el producto, sus usuarios o la continuidad del negocio y establecer un orden razonable de prioridades.
Durante la fase inicial, el equipo debe definir los activos críticos, las funciones de cada tipo de usuario y los posibles puntos de entrada al sistema. Este análisis permite decidir qué controles son imprescindibles para el producto mínimo viable y cuáles pueden incorporarse conforme aumenten la complejidad y el volumen de operaciones.
Antes del lanzamiento, conviene verificar los permisos, proteger las credenciales, revisar las dependencias externas y probar los escenarios de fallo más relevantes. Si la plataforma maneja fondos o utiliza contratos inteligentes que controlan activos, el nivel de revisión debe ser mayor que el de una aplicación que solo publica información general.
Una vez en producción, la startup necesita mantener las dependencias actualizadas, supervisar eventos relevantes, registrar las acciones críticas y disponer de un procedimiento de respuesta ante incidentes. También debe establecer quién puede tomar decisiones de emergencia y cómo se recuperará el servicio si una parte de la infraestructura queda comprometida.
Esta planificación puede resumirse en una regla operativa: proteger primero aquello cuya pérdida o manipulación tendría las consecuencias más graves para el negocio.
La seguridad debe evolucionar con la empresa. Una plataforma que comienza con veinte clientes y gestiona información pública puede necesitar una arquitectura distinta cuando incorpora cientos de organizaciones, integra sistemas corporativos o empieza a procesar información confidencial. Revisar los riesgos después de cada cambio significativo ayuda a evitar que el crecimiento introduzca vulnerabilidades que el diseño inicial no contemplaba.
El papel de la automatización y la inteligencia artificial
La automatización puede facilitar la aplicación continua de controles de seguridad sin obligar a una startup a ampliar de forma desproporcionada su equipo técnico. Las herramientas de análisis de dependencias, las pruebas automatizadas y la supervisión de eventos permiten identificar determinados problemas antes de que afecten a los usuarios.
Por ejemplo, una startup puede integrar comprobaciones de seguridad en su proceso de publicación de software para detectar dependencias vulnerables o impedir que una modificación llegue a producción cuando incumple requisitos definidos. En una plataforma con contratos inteligentes, las pruebas pueden verificar que determinadas operaciones respetan límites y condiciones establecidos.
La inteligencia artificial también puede ayudar a identificar patrones anómalos en los registros de actividad o priorizar alertas. Sin embargo, no debe convertirse en la única barrera de protección. Sus resultados pueden contener errores y, si se utilizan para bloquear operaciones o restringir cuentas automáticamente, necesitan límites, supervisión y mecanismos de revisión.
La observabilidad completa esta estrategia. La startup debe disponer de información suficiente para detectar comportamientos anómalos, reconstruir incidentes y entender qué componentes se han visto afectados. Esa capacidad debe equilibrarse con la privacidad: recopilar más información de la necesaria puede aumentar los riesgos en lugar de reducirlos.
Errores que una startup debe evitar
Uno de los errores más frecuentes es considerar que la descentralización garantiza la seguridad. Distribuir la infraestructura puede reducir ciertos puntos únicos de fallo, pero no elimina los problemas relacionados con las claves, los permisos, los errores de programación o la información falsa.
También resulta arriesgado confiar exclusivamente en una auditoría puntual. Una revisión favorable no garantiza que el sistema siga siendo seguro después de introducir nuevas funcionalidades, cambiar dependencias o integrar servicios externos. La protección debe mantenerse durante todo el ciclo de vida del producto.
Otro error consiste en almacenar información sensible en una blockchain pública sin analizar previamente las consecuencias. La inmutabilidad puede dificultar la corrección de exposiciones accidentales y generar conflictos con las obligaciones de privacidad. La arquitectura debe determinar qué información necesita registrarse, qué datos pueden mantenerse fuera de la cadena y cómo se limitará el acceso.
Por último, la startup no debería presentar la seguridad como una garantía absoluta. Ninguna arquitectura elimina todos los riesgos. La confianza se construye explicando los controles implementados, las limitaciones existentes y los procedimientos previstos para gestionar incidentes.
Conclusión: la seguridad también forma parte del producto
La seguridad por diseño permite que una startup integre la protección de sus activos, usuarios y operaciones en las decisiones que definen su arquitectura. Su aplicación no exige comenzar con sistemas innecesariamente complejos, sino comprender qué riesgos son relevantes y establecer controles proporcionados desde las primeras fases del desarrollo.
Los ejemplos de trazabilidad, mercados digitales y credenciales verificables muestran que la seguridad puede mejorar la propuesta de valor, facilitar las relaciones entre organizaciones y reducir la incertidumbre en operaciones digitales. En plataformas descentralizadas, esta capacidad resulta especialmente importante porque la confianza debe sostenerse entre participantes que no dependen necesariamente de una misma autoridad.
El objetivo no es construir sistemas que prometan ser invulnerables, sino plataformas capaces de prevenir fallos previsibles, limitar sus consecuencias y recuperarse cuando se producen. Para una startup, esa capacidad constituye una ventaja operativa y comercial: permite crecer con mayor previsibilidad y demostrar que la confianza no depende únicamente de una promesa, sino también de cómo se ha diseñado y cómo se gestiona el sistema.
Nota: Este artículo es informativo y divulgativo. No constituye asesoramiento jurídico, financiero, tecnológico o empresarial. Las medidas de seguridad deben adaptarse a los riesgos, requisitos normativos y características de cada proyecto. No estamos afiliados ni alineados con ninguna de las herramientas, tecnologías o empresas mencionadas.