Una empresa de desarrollo Web3 no es simplemente un equipo que escribe Solidity o conecta una wallet a un frontend. Los proveedores más sólidos combinan ingeniería de protocolos, seguridad en smart-contracts, diseño de infraestructura, indexación de datos, conciencia regulatoria y entrega de productos en un proceso unificado y responsable. Esa distinción es importante porque los fallos en la capa de integración —no solo en el código del contrato— han causado pérdidas de cientos de millones de dólares.
El exploit en el puente Ronin en marzo de 2022 resultó en aproximadamente $625 millones sustraídos después de que los atacantes comprometieron las credenciales de los validadores. El exploit en el puente Wormhole en febrero de 2022 causó alrededor de $320 millones en pérdidas por una falla en la verificación. Estos incidentes demuestran por qué los servicios de desarrollo Web3 deben abordar aspectos como gestión de llaves, validación de mensajes, monitoreo, controles de despliegue y gobernanza operativa junto con la funcionalidad de la aplicación.
Esta guía explica cómo evaluar una empresa consultora de Web3, qué debe incluir un desarrollo Web3 personalizado, cómo comparar modelos de entrega y por qué la creación de dashboards para Web3 requiere una arquitectura de datos dedicada en lugar de una simple colección de gráficos frontend.
¿Qué ofrece realmente una empresa de desarrollo Web3?
Una empresa de desarrollo Web3 ofrece ingeniería integral para aplicaciones descentralizadas, infraestructura blockchain, sistemas de smart-contracts, plataformas de datos y herramientas operativas. Su responsabilidad abarca desde el descubrimiento técnico y la arquitectura hasta el despliegue, monitoreo, pruebas de seguridad, actualizaciones y documentación. El mejor proveedor es responsable del comportamiento del sistema en toda la pila, no solo de entregar código fuente aislado.
En la práctica, un compromiso serio suele cubrir varias capas conectadas:
- Arquitectura del producto y protocolo: Definir journeys de usuario, supuestos de confianza, flujos económicos, permisos y requisitos de actualización.
- Ingeniería en smart-contracts: Implementar lógica de tokens, staking, préstamos, gobernanza, mercados, puentes o tesorería.
- Integración frontend y wallets: Soporte para flujos de firma, cambio de cadenas, simulación de transacciones, manejo de errores y abstracción de cuentas donde sea apropiado.
- Backend y indexación: Construcción de pipelines de eventos, APIs, análisis, sistemas de notificación y procesos de conciliación.
- Infraestructura: Gestión de proveedores RPC, nodos archive, relayers, custodia de claves, entornos de despliegue, observabilidad y recuperación ante desastres.
- Aseguramiento de seguridad: Modelado de amenazas, revisiones de código, pruebas, pruebas de penetración y preparación para incidentes.
- Coordinación regulatoria y operativa: Vincular el diseño técnico con clasificación de tokens, licencias, protección de datos y requisitos de acceso al mercado.
Por lo tanto, la frase servicios de desarrollo Web3 debe considerarse como una categoría de entrega amplia, no como sinónimo de “programación de smart-contracts”. Una plataforma de staking puede contener contratos, una aplicación web, oráculos de precios, un motor de cálculo de recompensas, un subgraph, una wallet multisignature para la tesorería y varios roles operativos privilegiados. Un defecto en cualquiera de estos componentes puede comprometer el producto.
En Soken, nuestra metodología comienza mapeando activos, límites de confianza, acciones privilegiadas, dependencias externas y estados de fallo antes de finalizar las decisiones de implementación. Esto suele identificar riesgos que una revisión solo de código pasaría por alto, como un relayer inseguro, manejo inconsistente de decimales entre servicios o un rol de administrador que puede saltarse restricciones económicas.
Entregables típicos
| Área de entrega | Salidas típicas | Riesgo principal si se omite |
|---|---|---|
| Descubrimiento | Requisitos, modelo de amenazas, registro de decisiones arquitectónicas | Construir el modelo de confianza incorrecto |
| Capa de protocolo | Contratos, interfaces, scripts de despliegue, pruebas | Fallos en lógica o permisos |
| Capa de aplicación | Interfaz web/móvil, flujos en wallet, UX de transacciones | Errores en firma y pérdida de usuario |
| Capa de datos | Indexadores, APIs, análisis, conciliación | Saldos incorrectos o reportes obsoletos |
| Infraestructura | CI/CD, acceso a nodos, secretos, monitoreo | Incidentes no detectados o irrecuperables |
| Aseguramiento | Remediación de auditorías, pruebas de penetración, runbooks | Desplegar sin evidencia de control |
Un proveedor también debe explicar qué no construirá. Por ejemplo, un servicio de oráculos, sistema de custodia, red de validadores de puente o componente de pagos en fiat puede requerir proveedores especializados y aseguramiento separado. Los límites claros son signo de madurez en ingeniería, no de capacidad limitada.
¿Cómo deben elegir los fundadores entre una consultora de Web3 y un equipo interno?
Los fundadores deben optar por una consultora Web3 cuando necesiten experiencia especializada en blockchain, un camino de entrega acelerado, supervisión independiente de seguridad o acceso temporal a capacidades de protocolo, infraestructura y cumplimiento. Un equipo interno suele ser preferible para la propiedad a largo plazo del producto y iteraciones rápidas, pero requiere tiempo para reclutar especialistas y establecer procesos seguros de ingeniería.
La decisión debe basarse en riesgo, madurez del producto y capacidades requeridas en cada fase.
| Requisito | Consultora Web3 | Equipo interno | Modelo hibrido |
|---|---|---|---|
| Arquitectura inicial | Acceso rápido a especialistas | Más lento por reclutamiento | La consultora lidera, el equipo acompaña |
| Contexto del producto | Requiere descubrimiento estructurado | Conocimiento institucional fuerte | Propiedad compartida |
| Experiencia en smart-contracts | Capacidades especializadas profundas | Depende del reclutamiento | Revisión externa + entrega interna |
| Independencia en seguridad | Más fácil de obtener revisión separada | Potencial conflicto de intereses | Aseguramiento externo independiente |
| Mantenimiento a largo plazo | Puede requerir retainer | Mayor propiedad | Propiedad interna con soporte especializado |
| Perfil de costos | Tarifa diaria más alta, menor tiempo de setup | Costes fijos mayores | Balanceado |
| Flexibilidad de contratación | Inmediata | Limitada por reclutamiento | Contrataciones específicas con el tiempo |
Un error común es suponer que tercerizar el desarrollo transfiere la responsabilidad. No es así. El propietario del proyecto sigue siendo responsable de aprobar el modelo de confianza, controlar las llaves de producción, validar dependencias de terceros y asegurar que las suposiciones de negocio se codifiquen correctamente.
Un modelo práctico es dividir la responsabilidad en tres etapas:
- Definición de arquitectura y riesgos: Utilizar especialistas externos para desafiar las hipótesis y documentar límites de seguridad.
- Construcción y validación: Combinar la experiencia en protocolos de la consultora con la propiedad interna del producto.
- Transición operativa: Requerir runbooks, transferencia de conocimientos de despliegue, propiedad del monitoreo y un período definido de soporte post-lanzamiento.
En nuestra experiencia en Soken, los compromisos más sólidos usan una matriz de responsabilidades escrita. Identifica quién puede desplegar contratos, quién aprueba actualizaciones, quién controla las acciones en la tesorería, quién responde a alertas y quién puede pausar una función afectada. Sin esa matriz, los equipos a menudo descubren durante un incidente que varias personas asumieron que otro estaba monitoreando el sistema.
El proceso de selección de la consultora debe incluir preguntas técnicas en lugar de solo revisar portafolios:
- ¿Qué chains, máquinas virtuales, sistemas de indexación y standards de wallets soporta el equipo?
- ¿Cómo se gobiernan los contratos upgradeables?
- ¿Cómo se prueban llamadas externas, dependencias en oráculos y roles privilegiados?
- ¿Qué evidencia respalda la reproducibilidad del despliegue?
- ¿Quién posee el código fuente, las cuentas de infraestructura, la documentación y las credenciales operativas?
- ¿Qué pasa si el proyecto cambia de cadena o modifica la tokenomía?
- ¿Qué actividades de prueba y seguridad están incluidas en el alcance?
Una buena empresa de desarrollo dapp discutirá sobre estados de fallo en transacciones, reorganizaciones de cadena, gestión de nonce, estimación de gas y incompatibilidades de wallets — no solo el diseño de la interfaz.
¿Qué debe incluir un desarrollo Web3 personalizado?
El desarrollo Web3 a medida debe incluir una arquitectura documentada, un modelo de amenazas, componentes de protocolo testeados, servicios de datos resilientes, controles de despliegue seguros, infraestructura productiva observable y un plan de transferencia. La personalización es valiosa cuando el producto tiene requisitos económicos u operativos específicos, pero el código a medida solo debe introducirse donde cree valor medible o reduzca un riesgo conocido.
El término “a medida” a menudo se usa incorrectamente. Rebrandear una plantilla ya existente no es desarrollo personalizado, mientras que adaptar un componente open-source probado puede ser la decisión de ingeniería más segura. La pregunta relevante es si cada componente se ajusta a los supuestos de confianza y las restricciones operativas del proyecto.
Componentes clave en una construcción personalizada
1. Diseño de protocolo y económico
El equipo debe documentar cambios en suministro, flujos de tarifas, reglas del colateral, condiciones de liquidación, emisión de recompensas, autoridad para pausar y poderes de actualización. Cada variable económica requiere un dueño, una regla de validación y una respuesta ante valores anómalos.
2. Límites de contratos y aplicaciones
Los contratos deben aplicar invariantes críticos en lugar de depender del frontend para prevenir acciones no válidas. La app debe ofrecer vistas previas de transacción claras, simulaciones donde sea posible y mensajes de error comprensibles. Los servicios backend no deben convertirse en autoridades centralizadas silenciosamente, salvo que ese papel sea explícito y revelado.
3. Arquitectura de datos y indexación
Los datos de blockchain son orientados a append, asíncronos y susceptibles a reorganizaciones. Un indexer debe manejar eventos duplicados, transacciones revertidas, reorganizaciones, datos históricos ausentes y inconsistencias en proveedores. Los saldos mostrados en un dashboard deben ser conciliables con el estado on-chain.
4. Gestión de despliegue y actualizaciones
El despliegue en producción debe usar scripts versionados, aprobación multisignature, separación de entornos, seguimiento determinista de artefactos y un plan de rollback o pausa. Los contratos upgradeables necesitan más que un proxy; requieren controles de gobernanza, validación de disposición de almacenamiento y comunicación de cambios.
5. Pruebas y aseguramiento
Las pruebas deben combinar unitarias, invariantes, integración, de bifurcación, fuzzing, análisis estático, revisión manual y simulacros operativos. El marco de trabajo [Secure Software Development Framework] de NIST, SP 800-218, proporciona una referencia útil; la guía de OWASP ayuda a estructurar el análisis de riesgos de aplicaciones y APIs.
Consejo de seguridad: La defensa más efectiva contra una falla costosa en Web3 no es una auditoría única. Es una cadena de controles —Modelado de amenazas, pruebas de invariantes, despliegue con privilegios mínimos, monitoreo y simulacros de incidentes— que evitan que una sola suposición pasiva en la seguridad se convierta en pérdida en producción.
Un repaso a incidentes históricos ilustra por qué esta capa de defensa en capas importa. Euler Finance perdió aproximadamente $197 millones en marzo de 2023 tras un ataque que involucró lógica de donación y liquidación. El incidente no fue solo un problema frontend; involucró interacción entre la contabilidad del protocolo, flujos de tokens y transiciones de estado controladas por el atacante. En agosto de 2021, Poly Network sufrió un exploit inicialmente estimado en aproximadamente $611 millones, involucrando lógica cross-chain y de ejecución privilegiada.
Para equipos que construyen productos regulados o enfocados al mercado, también es necesario coordinar la arquitectura técnica con análisis legal. Los derechos de tokens, arreglos de custodia, reclamaciones de marketing, estructuras de gobernanza y geografía del cliente pueden afectar los requisitos de implementación. Los servicios legales en crypto de Soken apoyan en opiniones jurídicas, clasificación de tokens y cumplimiento normativo junto con la entrega técnica.
Los servicios de desarrollo y seguridad Web3 de Soken combinan arquitectura, entrega de aplicaciones, revisión de smart-contracts, pruebas de penetración y aseguramiento de infraestructura. El alcance adecuado depende de si el proyecto requiere una nueva dapp, remediación de protocolos, creación de dashboards o un programa de ingeniería más amplio.
¿Cómo funciona la creación de dashboards para Web3?
La creación de dashboards en Web3 requiere una pipeline de datos verificable que convierta eventos on-chain asíncronos en información oportuna, conciliada y con permisos controlados. Un dashboard de producción debe distinguir entre estado confirmado y pendiente, exponer la proveniencia de los datos, manejar reorganizaciones y evitar que los usuarios consideren una indexación incompleta como información financiera definitiva.
Un dashboard para un protocolo DeFi se asemeja más a un sistema de control operativo que a una página analítica convencional. Puede mostrar valor total bloqueado, ratios de colateral, emisiones de recompensas, saldos de tesorería, propuestas de gobernanza, rendimiento de validadores, colas de liquidación o mensajes cross-chain. Cada métrica tiene una fuente diferente, frecuencia de actualización, nivel de confianza y modo de fallo.
Arquitectura recomendada para dashboards
-
Fuentes de datos blockchain
Utiliza endpoints RPC confiables, acceso a archive cuando las consultas históricas lo requieran y listeners de eventos para contratos relevantes. Los saldos críticos deben verificarse contra lecturas directas del contrato o una fuente independiente. -
Ingesta y normalización
Convertir eventos raw en un modelo interno coherente. Considerar decimales de tokens, actualizaciones en contratos, identificadores de cadena, direcciones proxy y cambios en el esquema de eventos. -
Capa de conciliación
Comparar el estado indexado con el estado on-chain en intervalos programados. Marcar discrepancias en lugar de sobrescribirlas silenciosamente. -
API y controles de acceso
Separar análisis públicos de datos operativos privilegiados. Aplicar autenticación, autorización, límites de tasa, registros de auditoría y protección contra inyecciones y ataques de denegación de servicio. -
Frontend y alertas
Mostrar timestamps, números de bloque, estado de confirmación y etiquetas de origen. Las alertas críticas deben llegar a un responsable mediante más de un canal.
Tipos de dashboards y prioridades de diseño
| Tipo de dashboard | Métricas clave | Controles críticos |
|---|---|---|
| Protocolo DeFi | TVL, utilización, colateral, actividad de liquidación | Actualidad del oracle y conciliación |
| Tesorería | Saldos de activos, transferencias, aprobaciones, vesting | Rastreo multisignature |
| Gobernanza | Propuestas, quórum, poder de voto, estado de ejecución | Consistencia entre snapshot y ejecución |
| Operaciones de puente | Mensajes, validadores, confirmaciones, retrasos | Prevención de replays y alertas de anomalías |
| Mercado de NFT | Listados, ventas, regalías, propiedad | Orden de eventos e integridad de metadatos |
| Validadores o nodos | Tiempo de actividad, tareas fallidas, salud de pares | Escalado de alertas y redundancia |
Un dashboard nunca debe implicar certeza donde los datos son provisionales. Por ejemplo, una transacción incluida en un bloque puede luego ser afectada por una reorganización, mientras que un mensaje cross-chain puede emitirse en una red pero no estar aún finalizado en otra. Etiquetas como “pendiente,” “confirmado,” “finalizado” y “reconciliado” son controles operativos, no detalles cosméticos.
El enfoque de Soken en la creación de dashboards para Web3 inicia con un diccionario de métricas: cada valor que se muestra tiene una definición, fuente, método de cálculo, intervalo de actualización, tolerancia esperada y dueño responsable. Esto evita disputas donde equipos de producto, finanzas y ingeniería usen el mismo término —como “saldo de la tesorería”— para significar cosas diferentes.
Luego de definir el modelo de datos, el siguiente paso es una revisión independiente de la aplicación, contratos, APIs e infraestructura. Los equipos pueden usar el Security X-Ray de Soken para una evaluación preliminar de seguridad antes de solicitar una revisión más profunda.
Recomendación principal: Si tu producto depende de interacciones con contratos, flujos privilegiados o datos en blockchain, utiliza los servicios de desarrollo, auditoría y penetration testing en Web3 de Soken para validar la arquitectura y los controles de entrega antes del lanzamiento en producción. Los riesgos anteriores—manejo de reorganizaciones, accesos privilegiados, conciliación y gobernanza de despliegue—son precisamente donde una evaluación técnica integrada aporta mayor valor que solo revisar el frontend.
¿Qué controles de seguridad debe demostrar una empresa de desarrollo Web3?
Una empresa de desarrollo Web3 debe demostrar seguridad mediante evidencia concreta: modelos de amenazas, resultados de pruebas, diseño de controles de acceso, despliegues reproducibles, gestión de dependencias, planes de monitoreo, runbooks para incidentes y revisiones independientes. Las afirmaciones de experiencia no sustituyen artefactos que muestren cómo el proveedor identifica, mitiga y verifica riesgos en todo el ciclo de entrega.
El paquete mínimo de evidencia debe incluir:
- Modelo de amenazas: activos, atacantes, límites de confianza, casos de abuso y riesgos residuales aceptados.
- Inventario de permisos: dueños, operadores, pausadores, administradores de actualizaciones, relayers, oráculos y roles de emergencia.
- Registro de pruebas: cobertura en pruebas unitarias, de integración, fuzzing, invariantes, bifurcaciones, caminos negativos y regresiones.
- Registro de dependencias: librerías de contratos, APIs, proveedores RPC, indexadores, puentes, oráculos y servicios en la nube.
- Controles de despliegue: separación de entornos, aprobación multisignature, gestión de secretos, hashes de artefactos y registros de cambios.
- Plan de monitoreo: eventos y umbrales para retiros anómalos, cambios en roles, desviaciones en oráculos, transacciones fallidas y fallos en servicios.
- Respuesta a incidentes: contactos, niveles de escalada, autoridad para pausar, conservación de evidencias, comunicaciones con usuarios y decisiones de recuperación.
La gestión de accesos merece atención especial. Las llaves para despliegue en producción no deben estar en la laptop de un solo desarrollador, y los permisos administrativos deben limitarse por rol y alcance. La comprometedora en las llaves de validadores en el incidente Ronin muestra cómo la seguridad operacional puede derrotar un diseño de protocolo sofisticado.
También debe explicarse cómo maneja la empresa los fallos específicos de Web3, como:
- Reorganizaciones de cadena y diferencias en finalidad
- Replays entre redes
- Identificadores de cadena incorrectos y separadores de dominio
- Abuso en aprobaciones de tokens
- Estanqueidad o manipulación de oráculos
- Colisiones en almacenamiento proxy
- Mismatches en precisión y decimales
- Denegación de servicio por inputs de gas alto
- Fallos en llamadas externas y ejecuciones parciales
- Ausencias en dependencias y límites de tasa
En nuestros auditorías, tratamos el “pause” como un mecanismo de seguridad cuidadosamente gobernado, no como una solución universal. Un pause que no pueda activarse rápidamente es inútil; uno que sea desencadenado por una cuenta no protegida genera un riesgo adicional de centralización y compromiso.
Los proyectos también pueden revisar los informes de auditoría publicados de Soken para entender cómo se estructuran, priorizan y vinculan los hallazgos con las remediaciones. La calidad de una auditoría se valora mejor inspeccionando su metodología y profundidad técnica, no solo contando páginas del reporte.
¿Cómo gestionan los equipos la entrega, el cumplimiento y las operaciones a largo plazo?
Los equipos pueden gestionar efectivamente la entrega de Web3 tratando el lanzamiento como una transición controlada hacia las operaciones, no como el fin del desarrollo. El proyecto debe contar con dueños nombrados, puertas de lanzamiento medibles, supuestos legales documentados, cobertura de monitoreo, procedimientos de actualización y una programación de revisión pos-lanzamiento antes de exponer activos o usuarios a contratos en producción.
Una secuencia de entrega práctica incluye:
-
Definir los límites del producto
Identificar qué queda en on-chain, off-chain, custodial, permissionless, permissioned o depende de terceros. -
Registrar decisiones arquitectónicas
Documentar selección de cadenas, uso de puentes, opciones de actualización, diseño de oráculos, indexación, soporte de wallets y retención de datos. -
Construir la mínima versión segura
Limitar la funcionalidad inicial y exposición de activos. Evitar lanzar combinaciones no probadas de gobernanza, apalancamiento, messaging cross-chain y liquidez automatizada. -
Validar adversarialmente
Testear entradas inválidas, tokens maliciosos, precios manipulados, roles comprometidos, datos obsoletos, llamadas RPC fallidas y condiciones de cadena inesperadas. -
Releasear mediante gates
Requerir revisión de código, pruebas finalizadas, aprobación de despliegue, preparación del monitoreo y confirmación de contacto en incidentes. -
Operar y reevaluar
Revisar alertas, actividad privilegiada, cambios en dependencias, reportes de usuarios y supuestos económicos tras el lanzamiento.
El cumplimiento debe vincularse tempranamente con la arquitectura del producto. La jurisdicción, perfil del cliente, modelo de custodia, derechos de tokens, controles de sanciones y estrategia de marketing pueden afectar la incorporación, restricciones de acceso, monitoreo de transacciones y gestión de registros. Los Crypto Map de Soken ayudan a comparar entornos regulatorios en discusiones de jurisdicción y planificación de mercado.
El mantenimiento a largo plazo también requiere claridad contractual. La declaración de trabajo debe especificar tiempos de respuesta a vulnerabilidades, cadenas soportadas, actualizaciones en dependencias, disponibilidad en emergencias, propiedad intelectual, estándares de documentación y proceso para modificar alcances. Un presupuesto inicial bajo puede convertirse en costoso si cada problema en producción se trata como un nuevo proyecto.
El Soken Hub ofrece un centro para explorar investigaciones y guías relacionadas con ingeniería Web3, seguridad y aspectos regulatorios. Para proyectos complejos desde el punto de vista técnico, es útil organizar estos materiales en un registro de decisiones interno que ayude a futuros desarrolladores a comprender por qué se eligió una cadena, un modelo de proxy, un oracle o un pipeline de datos específico.
¿Cómo evaluar una empresa de desarrollo dapp antes de cerrar?
Deberías evaluar a una empresa de desarrollo dapp mediante descubrimiento técnico, evidencia de entregas comparables, metodología de seguridad, términos de propiedad y preparación operativa. El proceso de selección más sólido combina un ejercicio arquitectónico escrito con una revisión de entregables de muestra, en lugar de apoyarse solo en un pitch, un prototipo visual o una lista de chains soportadas.
Usa esta lista de verificación:
Capacidad técnica
- ¿Puede la empresa explicar todo el ciclo de vida de una transacción?
- ¿Entiende errores en wallets, conflictos de nonce, estimaciones de gas y finalidad de cadenas?
- ¿Puede diseñar indexación y conciliación en lugar de solo pantallas frontend?
- ¿Prueba roles privilegiados e invariantes económicos?
- ¿Puede operar el sistema tras el despliegue?
Madurez en seguridad
- ¿Incluye modelado de amenazas antes de programar?
- ¿Se rastrean los hallazgos de auditoría hasta su remediación y nuevas pruebas?
- ¿Se documentan dependencias y servicios de terceros?
- ¿Se aíslan y gobiernan las llaves de producción?
- ¿Incluye respuesta a incidentes en el plan de lanzamiento?
Términos comerciales y de propiedad
- ¿Quién posee los repositorios, scripts de despliegue, cuentas de infraestructura y documentación?
- ¿Se revelan licencias open-source y componentes de terceros?
- ¿Qué soporte incluye?
- ¿Qué niveles de servicio aplican a vulnerabilidades críticas?
- ¿Cómo se tasan las migraciones de cadenas y cambios en protocolos?
Calidad del producto y comunicación
- ¿El proveedor desafía asunciones inseguras del producto?
- ¿Los hitos tienen criterios de aceptación medibles?
- ¿Se explican claramente los riesgos a stakeholders no técnicos?
- ¿Se distingue entre prototipo y sistema listo para producción?
Un ejercicio final útil es pedir al proveedor que identifique cinco formas en que el producto podría fallar y que las clasifique por probabilidad e impacto. Un equipo maduro discutirá escenarios incómodos —como una caída de oracle, operador comprometido, decimales incorrectos, datos obsoletos o un fallo en actualización— sin tratar esas preguntas como obstáculos para cerrar.
Una consultora Web3 debe ser juzgada por la calidad de sus decisiones bajo incertidumbre. Frameworks, librerías y chains cambian, pero análisis de amenazas, despliegue controlado, datos verificables y operaciones responsables son indicadores duraderos de calidad en la entrega.
El paso más confiable es preparar una matriz de límites del sistema y responsabilidades en una página antes de elegir un proveedor. Incluye contratos, wallets, APIs, dashboards, terceros, roles privilegiados y usuarios previstos; y pide a cada candidato que identifique los caminos de fallo de mayor impacto.