Your data stays yours.

Who you are contracting with

The contracting party is POLARGATE, S.L., a Spanish limited company with a sole administrator, registered and tax domiciled in Madrid, Spain, with an EU VAT number for work outside Spain. Contracts, invoices and liability sit with that company.

Polargate's registered office is in Madrid, and we work from Madrid and Amsterdam. Pedro Ciordia, founder and CTO, leads the technical direction and the reviews; Andrés Ciordia, Chief AI Officer, leads the AI side. If your supplier process requires a vendor with a compliance department, this page tells you in five minutes whether we clear your bar, instead of in week three.

Where your data lives and who else touches it

In your own accounts

We build on Postgres with row level security (Supabase), static hosting (Vercel) and a private Git repository. Where the project allows it, those accounts are opened in your name and billed to you, so the infrastructure is yours and we do not sublet it to you.

Subprocessors

Everything we build has a short list of subprocessors: the database and backend host, the web host, the source host, the model provider used during delivery, an embeddings provider when the project includes semantic search, a web crawl provider when the project includes market monitoring, and the email transport.

We do not publish one fixed global list, because the list depends on what we build for you. We send the named list, with the processing region of each service, in writing before you sign, and it becomes part of the contract. If a subprocessor changes during the engagement, you are told before the change, not after.

Data residency

We do not make a blanket claim that all data stays inside the EU. The region is chosen per project and written down before the first deploy. If EU only processing is a hard requirement, say so at kickoff: it changes provider choices, and it is cheap to decide before the first line of code and expensive afterwards.

The code and the content are yours

You own the repository from the first day, not on the last invoice. Nothing we build runs on a CMS of ours, on a licence you have to keep paying us, or on a runtime only we can operate. Sites are pre-rendered to static HTML and the content lives in your own database.

At handover you receive the repository, ownership of the backend project, the DNS records and the secrets. The test we hold ourselves to is simple: another competent team should be able to pick the project up without calling us. Standard stack, standard deployment chain, documentation inside the repository.

Continuity of service

Straight answer: your product keeps running, because it does not run on anything of ours. The repository is yours, the infrastructure is in your accounts where possible, and the deployment chain is off the shelf. There is no Polargate licence server, no proprietary runtime and no key that we hold and you do not.

The work does not depend on one person either. Each project has a named lead, with the technical review done from Madrid. Ongoing support is contracted through Care, as a block of hours with a response window agreed in writing, and you see the consumption in your portal and in the footer of every support email, so you always know what is left.

How we use AI in delivery and what a person reviews

We build with AI agents in the loop, then audit the result with several agents in parallel, and every finding is challenged by independent skeptical agents before we accept it. One recent audit ran 41 agents and produced 17 findings, each contrasted by two independent skeptics. In another check, a mechanical sweep of 300 cases showed that a rule we believed correct had been failing in 78 per cent of them; the corrected version came back with zero errors across the same 300.

A person reviews and signs off, and a person triggers the production deploy by hand. On the platforms we run, tests run on every development and staging build. Nothing reaches production because a machine decided it was ready.

Two limits worth stating plainly. First, code and documents you share with us are processed by the model providers we name to you, and their terms apply; we name them so your team can read those terms instead of taking our word for it. Second, secrets never go into a prompt or a repository. They live in an encrypted, audited vault behind a single gateway, every access is logged, rotation is versioned, and machine tokens are stored only as a hash.

The controls we do have

Each of these is a dated photograph of a system, not a permanent property of it.

Tenant isolation

Row level security is forced, and a guard discovers the tables that carry a tenant identifier instead of relying on a hand written list. In August 2026 it was watching 81 such tables and running in continuous integration, and the cross tenant test between two real tenants returned no leak on that run.

Separation between clients in our own systems

Our knowledge system keeps one client's material out of every other client through four independent layers: a database predicate, an application check with a test in CI, a table trigger and a revalidation of the request. As of 3 September 2026, 507 sources had been stopped by that wall before reaching any classifier.

Auditing and spend limits

Every call through our connector is logged, 8,463 of them at that same reading. An adversarial audit of our own access model produced 26 findings, 19 confirmed, all remediated and deployed. A second pass removed 13 row level security policies that granted global read to any internal user and added a ceiling of 200 AI calls per user per day.

Secrets

At the July 2026 reading, around 28 secrets lived in the vault, verified, with a per access audit trail and versioned rotation for rollback. Continuous integration reads from it to sign and publish applications, so no key has to be pasted anywhere.

External eyes and web hardening

An external consultant reviewed the security posture of one of our platforms in July 2026: 23 points, 11 closed at that reading. On sites we harden we serve HSTS, a Content Security Policy, X-Frame-Options, nosniff, a strict Referrer-Policy and a Permissions-Policy, and we remove server version fingerprints.

We do not have ISO 27001 or SOC 2

We have not had an external penetration test either, and we do not publish a standard data processing agreement today. Writing any of that differently would be a lie your auditor would find anyway.

What we do instead: we answer your questionnaire with the controls above, dated and with the evidence behind each one; we review and sign your data processing agreement as part of the contract; and we are open to a penetration test run by you or by your provider, at your cost and within a window agreed in writing.

We have no certification date to give you, because we have not started that process. When we do, the date appears on this page. If a certificate is a hard gate in your supplier framework, we will not clear it today, and you should know that now rather than in week three.

Procurement and vendor onboarding

What we can send you

• Company identification for vendor registration: legal name, CIF, EU VAT number, registered address and bank details for invoicing.
• A written architecture description of your project: components, data flows, where each piece runs, and the named subprocessor list with regions.
• The access and secrets model: who can reach what, how access is granted and how it is revoked.
• The deployment and rollback procedure, including who triggers production and how a release is reverted.
• Your security questionnaire, completed.

What we cannot send is anything that does not exist: certifications we do not hold and audit reports we have never had.

How we answer a security questionnaire

You get an acknowledgement with the name of the person who will answer it and a delivery date, and that date is the one we work to. A long custom questionnaire, or a supplier portal with its own forms, gets its date in that same first reply.

The answers are written by the engineer who built the system, not by a compliance team. That is slower on volume and more accurate on detail, and it means the person who answers question 74 is the person who can change the thing question 74 is about.

Who to talk to

Pedro Ciordia, founder and CTO, with the people who run your project. Everything comes in through the brief at /start. The engineers who build your system also answer the questionnaire, join the architecture call and review the contract, with no account manager layer in between.