AI controls

AI in Radplicity is not a switch with an on and an off. It has three states, because “we have not turned it on” and “we are not permitted to turn it on” are different answers and a buyer with a policy needs the second one to be recorded.

• Not activated. The default for every new organization. AI features are visible but inert until an administrator switches them on. Nothing is sent anywhere.
• Activated. An administrator has switched it on. AI drafting is available to the people whose roles permit it.
• Prohibited. A deliberate, recorded state for organizations whose policy forbids AI processing. It cannot be undone from inside the product by the customer’s own administrators, and it overrides everything else — plan, activation, role, and any internal flag.

Prohibition is checked first, before entitlement, before activation, and before any question about who is asking. A prohibited organization produces the same answer no matter which part of the product asks or how it asks.

It is checked twice on every request that would reach a model: once before anything is gathered, and again in the moment before the request would leave. The second check exists because the gap between those two points is where a policy change would otherwise be missed.

An unreadable policy is treated as a prohibition. If the record of what an organization allows cannot be read — a missing row, a database error — Radplicity refuses rather than proceeding. “We do not know what this organization permits” must never resolve to permission.

Turning a prohibition off is deliberately harder than turning it on. It cannot be done by the customer’s administrators from inside the product, and it cannot be done by Radplicity support staff on request.

It requires all of the following, together:

• A separately authorized platform role — not ordinary support access.
• A written reason.
• A traceable customer-approval reference — a ticket, a contract amendment, something that exists outside Radplicity. A person’s name typed into a box is not enough and is refused.
• An explicit confirmation that the customer asked for this.

The database enforces part of this rather than the application alone: the role Radplicity’s web application runs as has no permission to write the prohibition columns at all. A bug in the application cannot lift a prohibition, because the connection it holds is not allowed to.

Radplicity staff can see that an organization is prohibited, and the reason recorded. They cannot switch AI on for that organization, and they cannot use an internal flag or a support tool to work around it — prohibition is evaluated before any of those are consulted.

When a member of staff signs in as one of your users to investigate a problem, that session is limited, time-boxed and recorded against both identities, and it cannot take assessments, give acknowledgments, issue certificates or send messages on that person’s behalf.

This is application-enforced prohibition. That description is precise, and the precision matters.

All outbound AI requests pass through a single point in the code, and a build rule prevents any other part of the product from reaching a model provider directly. That is a strong control and it is not network isolation: a build rule governs source code, and source code is not a firewall.

Radplicity today runs as one application in one environment, so the provider credential is readable by the server-side code of that application. Genuine isolation would require separating that process and restricting outbound network access to it — infrastructure work we have not done and are not claiming.

We therefore do not claim dedicated infrastructure, network-level isolation, that no AI processing can occur anywhere in the system by any means, or that using these controls satisfies any particular law or regulation. What we claim is what is built: a prohibition that overrides every other setting, is checked before and immediately prior to dispatch, fails closed when unreadable, cannot be lifted by the application role, and requires an authorized role plus a traceable approval reference to remove.

All of it. Turning AI off — or prohibiting it — changes nothing about your configuration, your branding, your existing content, or how the product behaves. Courses, the course tree, materials, assessments, certificates, groups, catalogs, programs, learning paths, automation rules, imports, reporting and exports are unaffected, because none of them call a model.

What is unavailable is the drafting help: proposed course outlines and proposed quiz questions. Both are suggestions a person reviews before anything is saved, so nothing in your library depends on them.