El sistema ya se entregó, se pagó la última factura y la empresa volvió a la operación. Entonces aparece una pregunta sencilla: ¿quién corrige una integración cuando falla, quién cambia una regla del negocio y quién sabe dónde están las cuentas, los datos y las copias de seguridad?
El lanzamiento no responde eso. Si tu negocio necesita un responsable claro del software después del lanzamiento, esa responsabilidad debe estar definida antes del próximo cambio, no después de la primera emergencia.
Respuesta corta
- El proveedor que entrega un sistema puede seguir ayudando, pero la entrega y la responsabilidad continua son acuerdos distintos.
- La empresa debe controlar sus cuentas, datos, accesos y una forma de pedir cambios sin depender de la memoria de una sola persona.
- Un freelancer, una agencia o un responsable continuo pueden funcionar. El riesgo aparece cuando nadie responde por el mantenimiento, el contexto y la transición.
¿Qué necesita un responsable después del lanzamiento?
Después del lanzamiento, la pregunta no es solo quién escribe código. Es quién mantiene el sistema útil cuando cambia el negocio. Esa persona o equipo necesita un canal para recibir problemas, acceso suficiente para investigar y autoridad para explicar qué cambios son seguros.
Separa la responsabilidad en cuatro partes:
- Control: el hosting, los dominios, los servicios externos, el repositorio y las herramientas de pago deben estar vinculados a la empresa, con accesos individuales que puedan revocarse.
- Mantenimiento: alguien debe seguir las actualizaciones, los fallos, las copias de seguridad y las alertas. El acuerdo debe decir qué es soporte, qué es un cambio y qué ocurre fuera del horario normal.
- Contexto: alguien debe poder explicar las reglas del negocio, los datos y las conexiones entre sistemas. Sin eso, cada petición empieza con un nuevo descubrimiento.
- Transición: si el proveedor se va, otra persona puede hacerse cargo sin pedir una contraseña escondida ni depender de una conversación que solo existía en la cabeza de quien construyó el sistema.
La guía de la FTC para pequeñas empresas sobre la seguridad de proveedores, consultada el 16 de agosto de 2026, recomienda poner por escrito las expectativas de seguridad y tratamiento de datos, verificar su cumplimiento y mantener los controles actualizados. Es también un principio de compra: no entregues la operación a un proveedor sin acordar cómo se cuidará después.
¿Cómo saber si el proveedor puede mantener el sistema?
Un proveedor puede ser bueno entregando un proyecto y no ser la mejor opción para mantenerlo durante años. Antes de renovar o contratar soporte, pide respuestas concretas:
- ¿La empresa es dueña de las cuentas principales o todo está bajo el acceso del proveedor?
- ¿Qué incluyen el mantenimiento, las correcciones, las actualizaciones y las funciones nuevas?
- ¿Dónde están el código, los datos, las copias de seguridad y la documentación de la operación?
- ¿Quién responde si una integración falla fuera del horario normal?
- ¿Cómo puede la empresa exportar sus datos y contratar a otra persona?
- ¿Quién aprueba un cambio que afecta a las ventas, la facturación o la atención al cliente?
- ¿Cómo registra el proveedor qué cambió y por qué?
Si la respuesta es “habla con el desarrollador que lo sabe”, el problema ya apareció. El nombre del proveedor no sustituye una regla de acceso, un registro de cambios ni un plan de transición.
La plantilla de riesgo de proveedores de CISA para pequeñas y medianas empresas, consultada el 16 de agosto de 2026, incluye preguntas sobre actualizaciones, historial de parches, responsabilidad del cliente y continuidad del negocio. No necesitas copiar todo el documento. Usa sus preguntas para comprobar si el acuerdo sigue teniendo sentido después de la entrega.
La prueba más reveladora es un ejercicio de transición. Imagina que el proveedor no puede ayudar durante un mes. ¿La empresa sabe quién controla cada cuenta, dónde exportar los datos, qué rutina no puede detenerse y quién decide la próxima corrección? Si no lo sabe, la dependencia no está solo en el código. Está en toda la relación.
¿Freelancer, agencia o responsable continuo?
Las tres opciones pueden funcionar. La elección depende del trabajo que la empresa necesita mantener, no del nombre usado en la propuesta.
| Opción | Suele encajar cuando | Lo que debe quedar claro |
|---|---|---|
| Freelancer | El sistema es pequeño, el trabajo es ocasional y la empresa puede organizar el contexto | disponibilidad, cuentas a nombre de la empresa, documentación y sustitución |
| Agencia | Hay varias áreas que coordinar o un proyecto con entregas definidas | quién decide, quién ejecuta, soporte después de la entrega y acceso al historial |
| Responsable continuo | El software participa en la operación y cambia con el negocio | prioridades, canal de soporte, evolución, mantenimiento y continuidad |
Una agencia no es automáticamente más responsable que un freelancer. Un freelancer no está automáticamente más cerca del negocio. Lo importante es la combinación de acceso, contexto, disponibilidad y obligación de explicar lo que ocurrió.
Los modelos también se pueden combinar. Un freelancer puede entregar una mejora y un responsable interno cuidar la rutina. Una agencia puede construir el sistema y otro equipo asumir el mantenimiento. El acuerdo solo es seguro cuando el cambio se planifica, se documenta y se prueba.
¿Qué debe incluir el acuerdo antes de la próxima entrega?
No trates la transición como un archivo que se envía el último día. Haz que sea una parte verificable de la entrega. Esta lista es suficientemente corta para usarla en una reunión de compra:
- cuentas y dominios creados a nombre de la empresa;
- inventario de servicios, integraciones y permisos;
- instrucciones para los flujos operativos más importantes;
- ubicación de los datos y procedimiento de exportación;
- rutina de copia y restauración que alguien pueda explicar;
- registro de decisiones y cambios importantes;
- horario, canal y límites del soporte;
- condición para terminar la relación y transferir el trabajo.
Si el software gestiona datos de clientes, pedidos, pagos o empleados, el contrato también debe explicar cómo el proveedor accede, protege, devuelve y elimina esos datos. La FTC recomienda limitar el acceso a lo que el proveedor necesita y durante el tiempo que lo necesita. Es un requisito operativo que el dueño puede pedir sin saber programar.
¿Cuándo tiene sentido contratar responsabilidad continua?
Un responsable continuo tiene sentido cuando el sistema ya no es un proyecto aislado. Participa en ventas, servicio, inventario, facturación o una rutina que el equipo no puede pausar sin afectar la operación.
Otra señal es una cola de cambios pequeños. Si cada ajuste exige volver a descubrir el contexto, repetir la historia y esperar a que el proveedor original encuentre tiempo, la empresa está pagando por la falta de memoria del sistema. El trabajo continuo no requiere un equipo grande. Requiere que alguien mantenga las prioridades, el contexto, el acceso y la responsabilidad con el tiempo.
Eso no significa crear software a medida por reflejo. A veces la decisión correcta es mejorar la rutina o elegir software listo. El diagnóstico sobre cuándo dejar Excel para controlar el inventario muestra el mismo patrón: separa el problema de proceso, herramienta y responsabilidad antes de decidir quién debe hacerse cargo de la solución.
Preguntas para hacer antes de firmar
¿Quién debe controlar las cuentas?
La empresa debe poder entrar en las cuentas que sostienen su operación, con accesos individuales que puedan revocarse. El proveedor puede administrar el trabajo sin ser el único dueño de la infraestructura, los datos o los métodos de recuperación.
¿El código entregado basta para que otra persona se haga cargo?
No necesariamente. La transición también necesita datos accesibles, configuración, documentación, historial y una explicación del flujo del negocio. Pide una transición que otra persona pueda ejecutar, no solo una carpeta comprimida.
¿Un contrato de mantenimiento resuelve la falta de responsable?
No por sí solo. El contrato ayuda cuando define el alcance, el canal, el tiempo de respuesta, el acceso, los registros de cambios y la salida. Si nadie dentro de la empresa puede aprobar decisiones o explicar la operación, el soporte recibe peticiones sin contexto.
Conclusión
El software no está cuidado solo porque se lanzó. Está cuidado cuando alguien tiene acceso, contexto, tiempo y responsabilidad para mantener la operación y preparar el próximo cambio.
Antes de elegir un freelancer, una agencia o un responsable continuo, responde cuatro preguntas: ¿quién controla, quién mantiene, quién decide y quién se hace cargo si la relación termina? Si la respuesta depende de una sola persona, convierte la transición en parte del trabajo. El sistema puede seguir siendo simple. La responsabilidad no puede seguir siendo invisible.
Fuentes
- Federal Trade Commission, “Cybersecurity for Small Business”, consultado el 2026-08-16, https://www.ftc.gov/business-guidance/small-businesses/cybersecurity
- Cybersecurity and Infrastructure Security Agency, “Operationalizing the Vendor SCRM Template for SMBs”, consultado el 2026-08-16, https://www.cisa.gov/sites/default/files/2025-08/Operationalizing_the_Vendor_SCRM_Template_for_SMBs_2025_Final_508.pdf
- Reddit, “For those who've had a tech person offer to build you something, how did it go?”, consultado el 2026-08-16, https://www.reddit.com/r/smallbusiness/comments/1vd9yd1/for_those_whove_had_a_tech_person_offer_to_build/
