Seguridad y propiedad
Make It Happen construye sistemas que corren en las cuentas del cliente, con control de acceso por roles, autenticación de dos factores, permisos a nivel de fila y rastro de auditoría de cada cambio de estado. La propiedad del código se define en la propuesta. No declaramos certificaciones.
Entregarle a un proveedor la lógica de originación, las reglas de comisión o las historias clínicas de tus pacientes no es una decisión menor, y un estudio que responde eso con un sello en una página no la respondió. Así que aquí está la postura dicha como mecanismo: dónde corre el sistema, quién puede llegar a él, qué queda escrito, de quién es el código y qué pasa con todo eso si nosotros dejamos de existir. Donde no afirmamos nada, lo decimos.
Un certificado lo expide un auditor. Esto es el mecanismo.
El acceso es por roles, y el permiso es por funcionalidad y no por persona, editado desde un panel y no desde el código. El ingreso lleva autenticación de dos factores. Las reglas corren a nivel de fila: un registro es visible solo para quien le pertenece, y eso no se esconde en la pantalla, se hace cumplir donde se leen los datos. Cada cambio de estado queda escrito en una historia de eventos: qué cambió, quién lo hizo, cuándo. No declaramos ninguna certificación, porque un certificado lo expide un auditor contra un alcance y una fecha, no un estudio hablando de sí mismo. Lo que un estudio sí puede construir es la parte que una auditoría revisa: el rastro de auditoría, el modelo de permisos y la documentación que explica los dos.
El sistema corre en tus cuentas, no en las nuestras.
Cada cuenta de la que depende el sistema se abre a tu nombre y se factura a ti: la base de datos, el alojamiento, el envío de correo, la analítica. Nosotros entramos como colaboradores, al nivel que exige el trabajo, y ese acceso es un interruptor que controlas tú. Nada queda secuestrado detrás de un ingreso que solo tenemos nosotros, y los registros de tus clientes no quedan en una cuenta del estudio al lado de los de otra empresa. Cuando la relación termina, nos quitas el acceso y el sistema sigue corriendo, porque nunca estuvo corriendo en otra parte.
El sistema viejo se integra por una frontera documentada, no se reemplaza por sorpresa.
No te pedimos botar el sistema del que tu negocio ya depende. Integramos contra sus interfaces documentadas y, donde puede emitirlos, contra webhooks. Donde no puede, leemos por calendario a través de una frontera que es de solo lectura por defecto, para que una integración no pueda dañar los registros que está leyendo. Antes de programar nada se escribe el mapeo: qué campos se mueven, en qué dirección, con qué frecuencia, cuál es el identificador que manda y qué pasa con una fila que no pasa la validación. Donde un sistema no tiene ninguna interfaz, lo decimos y dimensionamos el camino manual en vez de disimularlo.
Nada de lo que operas depende de que este estudio siga existiendo.
Es una pregunta justa para un estudio de dos socios sin equipo de entrega aparte, y la respuesta es estructural, no tranquilizadora. El sistema corre en tus cuentas y bajo tu facturación, así que nadie tiene que renovar nada por ti. El código vive en un repositorio tuyo desde el primer día, no desde la entrega. Está hecho sobre interfaces documentadas y herramientas de uso común, así que el grupo de ingenieros que puede retomarlo es grande: no hay código propietario nuestro atravesado en la mitad. La base que nosotros reutilizamos es proceso y generadores de nuestro lado; lo que te entregamos no depende de ella para correr.
Los datos de pacientes y de deudores cambian el diseño, no solo el papeleo.
Cuando los registros son historias clínicas o carpetas de crédito, la restricción se diseña desde el principio y no se agrega después. Quién puede leer qué se decide por rol y por campo: quien agenda una cita no abre una nota clínica, y quien cobra ve un saldo sin ver el expediente de análisis de riesgo. La retención es explícita: qué se guarda, por cuánto tiempo, y qué se borra o se anonimiza cuando ese tiempo se cumple, escrito en el esquema y no dejado a quien se acuerde. Abrir un registro individual queda registrado, para que «quién leyó esto» tenga respuesta. A un agente automático se le da la frontera más estrecha de todas: lee por el mismo modelo de permisos que una persona, con una identidad propia, limitado a las tablas y los campos que su tarea necesita, con escritura solo donde se le permite y escalamiento a una persona para todo lo demás, y con cada intercambio registrado. Lo que no afirmamos: no somos tu asesor de cumplimiento, no certificamos nada y no damos el visto bueno sobre si tu proceso cumple una norma. Construimos el mecanismo y la evidencia; tu abogado o tu auditor los juzga.
Es tuyo lo que pagaste.
El acuerdo lo deja por escrito antes de que alguien empiece.
Diga lo que diga el acuerdo, la entrega es la misma: arquitectura y modelo de datos, el modelo de permisos y qué alcanza cada rol, el manual de lo rutinario, cómo se despliega, cómo se restaura, qué se rompe primero bajo carga y qué hacer cuando se rompe, y las decisiones que se tomaron con la razón de cada una. La prueba no es que los documentos existan. Es que un ingeniero que nunca ha hablado con nosotros los lea y opere el sistema. Se escriben durante la construcción, no se arman en la última semana.
Preguntas que sí hacen los compradores
¿De quién es el código que ustedes escriben?
Depende del acuerdo, y la propuesta nombra la forma por escrito antes de que firmes. Sea cual sea, la entrega es la misma: la documentación para operar el sistema sin nosotros.
¿Dónde quedan guardados nuestros datos?
En cuentas abiertas a tu nombre y facturadas a ti: la base de datos, el alojamiento, el envío de correo, la analítica. Tú eliges la región donde la cuenta lo permite y nosotros entramos como colaboradores, al nivel que exige el trabajo. Tus registros no quedan en una cuenta del estudio, y quitarnos el acceso no apaga el sistema.
¿Qué pasa con el sistema cuando termina el contrato?
Nos quitas el acceso y el sistema sigue corriendo, porque ya estaba corriendo en tus cuentas. Te quedas con el repositorio, la documentación y el manual de operación. Donde conservamos una plataforma bajo licencia, los términos de cierre están en el mismo contrato: qué sigue, por cuánto tiempo y cómo se produce una exportación.
¿Tienen alguna certificación de seguridad?
No, y no vamos a insinuar que sí. Un certificado lo expide un auditor contra un alcance y una fecha; no lo expide un estudio sobre sí mismo. Lo que construimos es lo que una auditoría revisa: control de acceso por roles, permisos a nivel de fila, rastro de auditoría y la documentación que los describe.
¿Quién de su lado tiene acceso a producción?
Los dos socios, y nadie más. No hay un equipo de entrega aparte ni un tercero con llave. Los agentes escriben código bajo nuestra dirección; lo que llega a producción lo revisa y lo despliega uno de nosotros, desde una cuenta nombrada y con autenticación de dos factores. Puedes ver cada acceso en tu cuenta y quitarlo sin avisarnos.
¿Cómo evitan que un agente de IA lea datos que no debe?
El agente tiene identidad propia y pasa por el mismo modelo de permisos que una persona, sin llaves de servicio que se salten las reglas. Está limitado a las tablas y los campos que su tarea necesita, en solo lectura salvo que escribir sea parte de la tarea, y con categorías enteras de registro bloqueadas. Cada llamada queda registrada.
La parte posible de lo imposible.
Si tienes una idea que no debería funcionar, tráela. Te decimos qué parte es de verdad imposible y cuál es solo difícil. Casi siempre es la segunda.