«IA privada» pode significar cousas distintas: unha conta empresarial nun servizo externo, unha API cun contrato específico, un modelo nunha nube baixo control da organización ou servidores propios. A etiqueta non indica por si soa onde se procesan as consultas, quen ve os rexistros nin quen se ocupa das actualizacións.
A decisión debe empezar polo proceso. Un asistente que responde sobre manuais públicos non precisa a mesma arquitectura ca outro que consulta expedientes con datos persoais. Para comparar opcións, debuxa primeiro o camiño de cada dato e identifica a persoa responsable de cada paso.
Este artigo ofrece un método técnico de selección. A base xurídica, os contratos e as transferencias internacionais dun tratamento concreto deben revisarse cos responsables de protección de datos e asesoría xurídica.
Primeiro, debuxa o percorrido dos datos
Enumera a entrada do usuario, os documentos recuperados, o prompt que recibe o modelo, a resposta, os rexistros da aplicación e as copias de seguridade. Inclúe as ferramentas externas que procesan eses elementos. Retirar un modelo da nube non serve de moito se a aplicación envía os documentos a outro servizo para indexalos.
Mapa de comprobación para un asistente documental. Cada frecha necesita unha finalidade, un permiso e un destino coñecido.
- Persoa
Pregunta coa súa identidade e permisos.
- Aplicación
Filtra o acceso e prepara a consulta.
- Busca
Recupera só os fragmentos autorizados.
- Modelo
Procesa o prompt e produce unha resposta.
- Rexistros
Conservan o mínimo necesario para operar e investigar erros.
Esquema conceptual de Portocelo. O almacenamento de documentos, índices e rexistros pode estar en lugares distintos.
Antes de probar con datos reais, responde: onde se procesan as entradas? Que se almacena e durante canto tempo? Que persoas e provedores teñen acceso? Como se elimina unha consulta? Que cambia ao activar historial, trazas ou busca web? A AEPD pide estas comprobacións para os seus propios sistemas de IA xerativa, incluíndo metadatos, rexistros, retención e localización. É unha referencia de método, non unha regra que faga obrigatoria unha arquitectura única para toda empresa.
Cinco formas de despregar a mesma tarefa
| Opción | Control e carga operativa | Custos que revisar | Cando estudala |
|---|---|---|---|
| SaaS empresarial | O provedor opera o servizo; a organización configura usuarios, permisos e uso permitido. | Licenzas, límites, integración e saída dos datos. | Tarefa estándar con funcións suficientes e condicións aceptables. |
| API xestionada | A organización controla a aplicación; o provedor executa o modelo. | Uso, almacenamento opcional, desenvolvemento e monitorización. | Precisas integrar a IA nun proceso propio sen operar GPUs. |
| Nube privada ou dedicada | Maior control sobre rede, recursos e configuración; mantemento repartido segundo o contrato. | Capacidade reservada, operación, seguridade e picos de carga. | Necesitas illamento ou condicións de despregamento concretas. |
| Infraestrutura propia | A organización opera modelo, servidores, accesos, actualizacións e continuidade. | Equipos, enerxía, persoal, renovación e capacidade ociosa. | Hai un requisito verificable de control local e equipo para mantelo. |
| Híbrida | Cada tipo de tarefa vai a un contorno definido por regras explícitas. | Dúas operacións, enrutamento, probas e observabilidade. | Os datos e tarefas teñen esixencias distintas e o encamiñamento pode auditarse. |
«Nube privada» tampouco é unha garantía automática de residencia. A documentación de Microsoft Foundry distingue o lugar onde se gardan datos do lugar onde se procesan os prompts segundo o tipo de despregamento. Tamén describe funcións opcionais que conservan historial. Son condicións dese servizo concreto e poden cambiar; antes de contratar hai que revisar a modalidade exacta.
O mesmo ocorre cos rexistros. Amazon Bedrock documenta unha configuración de rexistro de invocacións que pode gardar entradas e saídas en CloudWatch ou S3. A aplicación propia tamén pode escribir prompts no seu sistema de observabilidade. A revisión debe abranguer todas esas capas, non só as condicións do modelo.
Exemplo de aplicación: consultar manuais internos
Unha empresa quere que o persoal busque procedementos técnicos e obteña respostas con ligazón á fonte. Parte dos documentos son públicos; outros inclúen incidencias internas. O primeiro piloto separa as coleccións, aplica os permisos do usuario antes da recuperación e comproba que a resposta cite un fragmento autorizado. A guía sobre asistentes documentais con RAG explica esa parte funcional.
Para os manuais públicos podería abondar unha API xestionada. Para as incidencias internas, o equipo compara unha API empresarial coas condicións axeitadas e un modelo nun contorno controlado. Non decide só pola localización: proba a calidade das respostas co mesmo conxunto de preguntas, mide latencia e calcula o esforzo de actualización. Se un modelo local omite información crítica ou non hai quen o manteña, o control adicional non resolve a tarefa.
Este é un exemplo de aplicación hipotético. Non representa unha implantación nin resultados dun cliente.
O custo real inclúe manter o sistema
Comparar só o prezo por consulta cun servidor GPU é incompleto. Unha instalación propia necesita capacidade para os picos, actualizacións do modelo e dependencias, control de accesos, rexistros, copias, resposta a incidentes e persoas de garda cando falla. Unha API require integración e supervisión, aínda que outra entidade opere a inferencia.
- Estima consultas por día e por hora punta, tamaño das entradas e tempo máximo de resposta.
- Mide nunha proba a calidade da tarefa completa, incluída a recuperación documental e a revisión humana.
- Separa investimento inicial de licenzas, consumo, infraestrutura, persoal e substitución de hardware.
- Calcula o custo dunha caída e define un procedemento manual ou unha vía alternativa.
- Repite a comparación cando cambien o volume, o modelo ou as condicións contractuais.
Non hai unha cifra de aforro universal: a opción máis económica depende do patrón real de uso e do nivel de servizo que precisa o proceso. Un piloto pequeno con medicións propias permite estimar mellor ca unha tarifa illada.
Privacidade e seguridade: responsabilidades antes de contratar
Se hai datos persoais, o RGPD esixe analizar finalidade, minimización, seguridade e as condicións dos encargados do tratamento; as transferencias internacionais requiren unha revisión específica. Aloxar os datos no propio edificio non elimina estes deberes. Tampouco unha rexión europea resolve por si soa a base xurídica ou os permisos internos.
Antes de conectar o sistema, documenta quen é responsable do tratamento, que datos entran, quen os pode consultar, onde se gardan copias e rexistros, como se atende unha solicitude de dereitos e que ocorre ao rematar o contrato. O equipo xurídico ou de protección de datos debe valorar o caso concreto, incluída a necesidade dunha avaliación de impacto.
A decisión técnica pode pecharse cunha ficha de dúas páxinas: tarefa, datos, destinos, opcións descartadas, proba de calidade, custo de operación, responsables e condicións de parada. O servizo de IA privada permite estudar esa arquitectura; a gobernanza da IA axuda a asignar revisións e responsables durante a operación.
Do coñecemento ao proceso
Onde deben vivir os teus datos e o teu modelo?
Podemos debuxar o fluxo real, probar alternativas coas mesmas tarefas e estimar quen operará cada peza antes de escoller infraestrutura.
Estudemos a arquitectura ↗Fontes e referencias
- AEPD: recomendacións para a xestión de IA xerativa na Axencia (xaneiro de 2026) · Consulta:
- EUR-Lex: Regulamento (UE) 2016/679, texto oficial do RGPD · Consulta:
- Microsoft Learn: datos, privacidade e seguridade de modelos vendidos por Azure en Foundry · Consulta:
- AWS: rexistro de invocacións de modelos en Amazon Bedrock · Consulta:



