Proceptio.AI opens your business systems to the assistants your people already use, one named person at a time.
Your assistants are rolled out and useful everywhere except where the numbers live. Those systems are closed, and they are closed for a good reason: nobody could answer who would be accountable for what an assistant read. This is where that answer lives, and where the record of it is kept.
We hold no AI and no data. No model, no inference bill, no copy of your figures. What we hold is the decision - who may reach what, with which tools, under whose rules - and the record of every time it was made.
She types what changed in the payroll plan since last week? into the assistant she already uses. What happens next takes about a second and none of it is visible to her. It is worth following anyway, because every turn in it was a decision somebody at your company made, and that is why the answer she gets is one you would stand behind.
She is asking about test, and she never had to say so. Each of your environments has its own address, so which one she is on is settled before anything else is, and nothing inside the question can change it. Had she arrived somewhere that could mean two, we would refuse and ask her to name one. Quietly picking is how a number ends up attributed to the wrong environment, and that mistake stays invisible until it is expensive.
Structural. Nobody configured this.She signed in with her work account through your own Microsoft sign-in, so joiners and leavers stay the process you already run. What reaches us is a verified identity and nothing else: no permissions travel with it. That is why a colleague who left on Friday gets nothing on Monday. There is no session to expire and no token to wait out, only a row that is no longer there.
Your identity provider decided this.Her access is one row: this person, this environment, these tools. Three checks narrow it further, and each can only take permission away, so their order cannot change the answer and no layer hands back what another refused. What survives is what her assistant is shown. So a tool she does not hold is never refused after being tried. It is simply not there, and it never becomes an option in the conversation.
You decided this.The read happens against your database, with your credential, at the moment she asks. Nothing was copied here in advance. The answer names the environment it came from, because an unlabelled number from the wrong environment is worse than no answer. Your administrator's own wording and vocabulary ride back with it: enough to shape how the assistant explains something, and structurally unable to widen what it reached.
Your system answered.Allowed or refused, with the reason as a name rather than a log line written for a developer. Seventeen of those names exist and a test freezes them, because this is data somebody will read in three years and it has to still mean the same thing then. A credential rejected before it reached any permission check is recorded too, so somebody guessing at your connector is visible rather than silent.
Nobody chooses this.| time | person | tool | outcome | reason |
|---|---|---|---|---|
| 09:14:02 | a.novak | describe_model | allow | - |
| 09:14:38 | a.novak | read_slice | allow | - |
| 09:15:11 | a.novak | crm_read_all | deny | skill_not_enabled |
A governed layer is invisible on an ordinary day, which is what makes it hard to argue for. It shows up on three particular days instead, and those are the ones worth deciding about beforehand rather than during.
Their access is a row, and their assistant carries no permissions of its own. Delete the row and their next question gets nothing. Not at the end of a session, not when something expires: on the next question. Nobody has to remember a further step, which matters, because the offboarding task that gets forgotten is always the one nobody could see.
That is the default behaviour of an ungoverned read rather than a worst case. It is what we found the first time an assistant was pointed at a real planning model: the person was scoped to one market, and the answer contained every market. This is the case a governed layer exists for. Her grant names her tools, your own rules narrow what those tools may reach, and where a connected system enforces permissions better than we could, we let it and say so.
Every question is in the trail with its outcome and its reason, refusals included. So is what the rules said at the time, because an instruction is drafted, approved by a named person, and kept rather than overwritten. The application cannot edit or delete a trail row; it refuses at the point of writing. Making that true at the database level as well is a deployment step we have not finished, and it is named below with the rest of them.
One decision sits under all three. Who somebody is and what they may reach are kept separate here. So a consultant who works on two of your clients is ordinary rather than a conflict, your development, test and production are three environments rather than one with a switch, and access is a single row naming a person, an environment and a list of tools: a thing you can read, change and revoke in one place.
What a statement of work must contain. What has to be true before a lead becomes a proof of concept. Which environment a change reaches first. That process exists, in a document, and an assistant that has never seen it will answer confidently around it. So we store the rule, short and approved and versioned, point at your document rather than copying it, and record each time something was checked against it.
| subject | rule | outcome | basis | pinned to |
|---|---|---|---|---|
| SOW‑2026‑114 | sow‑minimum‑contents | EvidenceMissing | AutomatedRead | rule v4 |
| SOW‑2026‑114 | sow‑minimum‑contents | EvidenceFound | HumanRead | rule v4 |
There is no word for "pass". Four outcomes exist: evidence found, evidence missing, partial, undetermined. "Pass" describes a human judgement that reading a document cannot make, and the word somebody reads in a dispute two years later has to be the word that was actually earned.
A model's reading is labelled as a model's reading, and only a named person upgrades it, by confirming. Every record pins the version of the rule it was judged against. Without that, whoever edits the live rule silently rewrites what every past check meant.
We keep no copy of your document. A record can prove one changed since it was checked; it cannot reproduce its contents, because your business data does not live here.
The version of this that fails is the one where somebody spends a fortnight filling in a form. So the first pass is ours. A session reads what you have connected - your planning model's dimensions, your pipeline and its stages, your document library, your boards - and drafts your vocabulary, your naming conventions and pointers to your own process documents, each line carrying a quote of what it was drafted from.
Everything it writes is a draft, and a draft reaches nobody. A proposal cannot arrive approved, however it was produced, and that is enforced where the writing happens rather than trusted. Your administrator reads them and keeps the ones that are right. Anything with no evidence behind it is refused outright, because a generated line with nothing under it is an assertion with no author.
And the honest limit: nothing here can tell you whether a drafted rule is correct. Every one is a proposal to a person, and the value of the exercise is exactly the attention they give it.
List my deals is answered by your CRM. Which deals past Contract Sent have no delivery folder is answered by nothing you own.
That question needs the CRM, the document library, and an agreed rule about how the two relate, and nothing in your estate holds all three. The agreed rule is the thing we store, so the answer comes from something a person signed off rather than from a guess about your filing.
The rule is approved once. The individual links are worked out fresh each time they are needed and stored nowhere, because their truth lives in your CRM rather than in our database, where a copy would be wrong within a week while still looking current. What we keep is the exceptions: each one a dated record, pinned to the version of the rule it was judged against.
It is the easiest sentence to say about a connector, and it is false more often than it is true. It depends on two things a vendor rarely states: whether the system can accept this person as an identity at all, and whether its API then enforces that person's permissions. We check both, per system, and the answer appears on the screen where you set the connection up rather than in a document you have to ask for.
| Connected system | Accepts your person's identity | Enforces that person's permissions | Whose narrowing you get |
|---|---|---|---|
| DocumentsSharePoint via Graph | yes | yes, per item | Microsoft's. We store no credential for it and add no filter of our own. |
| TasksClickUp | no | yes, per user | The vendor's, reached with that person's own token, held as a pointer, revocable on its own, and never usable for anybody else. |
| CRMHubSpot | no | no | Ours. A read returns only the records that person owns, and reading the whole pipeline is a separate tool somebody has to grant on purpose. |
| Planning modelSQL | no | no | Ours. The grant, the tool list, and your own row rules where you have them. This is the case governance exists for. |
Why publish the weak rows. Where the answer is "ours", there is no second access control behind us, and you should know that before you sign rather than during an incident. It also decides the design: we prefer the system's own enforcement wherever it exists, because that stores nothing. Twenty-six systems across six categories are modelled; four have working adapters today, and the console says plainly which is which rather than accepting a connection that would fail when somebody uses it.
Most of what a reviewer needs is a boundary rather than a feature: what crosses into our systems, what never does, and who else touches it on the way. Here it is in the shape it will be asked for.
Where it runs. Microsoft Azure, West Europe. Three sub-processors and no others: Azure for hosting, database and secrets; Microsoft Entra ID for identity federation; and Proceptio Identity, our own sign-in broker, which holds OAuth machinery and no permissions at all.
Your AI vendor is not one of them, and it is worth stating precisely because it is unusual. You bring your own assistant. Results flow from here to it under your agreement with that vendor. We make no call to any AI vendor, carry no inference cost, and hold no contract with one.
Retention. The request trail is kept for 730 days; the administrative trail for seven years, and it is never pruned. What gets enforced and what was promised are two separate constants with a test pairing them, because the failure that matters is a maintenance job quietly deleting evidence somebody is paying to keep.
If your review requires process isolation, this runs as a dedicated instance with only your environments reachable, and the software does not change. Isolation here is the grant rather than the deployment, so a separate instance is a decision you can make at signature instead of an architecture we would have to build for you.
This section is unusual on a page like this and it stays, because these are the sentences a security reviewer needs first, and because every one of them is something you would find out anyway, later, in a worse conversation.
Different from the section above. Those are boundaries and they are permanent. These are gaps, each one has an owner, and a competent review would surface every one of them anyway. We would rather hand you the list than have you find it.
The application refuses to modify or delete a trail row, and today that is a convention the database does not enforce, because the service still holds owner rights on it. The fix is two database identities: one that can only insert, and a separate maintenance identity that holds the delete used by retention. It is written, it is a deployment step rather than a code change, and it is not done.
ISO 27001 first, then SOC 2 Type II, in that order because our clients are European and it is their procurement clause rather than ours. Not begun until the platform was actually running: a management system over software that has never operated is a management system over a document, and an auditor asks for operational evidence. We will not name a certification date before a readiness assessment sets one.
None yet. Ten adversarial isolation reviews have been run internally, each one recorded with its findings and its fixes, and each one found something the tests and the searches had not. That is a rigorous process, not an independent result, and the difference is the whole point of booking the test.
The pruning job exists, runs in bounded batches, refuses to run silently below the retention commitment, and has never deleted anything, because nothing schedules it yet.
One dependency on our sign-in broker, with the fail-closed control already written and inert until the change lands. Passing your own person's identity through to documents waits on the same change, which is why the documents row in the table above is the one place your provider does the narrowing rather than us.
The platform is deployed and running, and the first client estate is in implementation. Nothing on this page describes software that does not exist; where something is designed rather than finished, it is in this list.
One hosted service, in Europe, run by us. There is nothing to install and nothing to migrate: your people paste an address into the assistant they already have. Adding a client is configuration rather than an engineering project, which is the whole economic argument, and also why your setup is yours rather than a copy of somebody else's.