Assign every review. Keep the evidence on file.
Give each reviewer the evidence they need. Security reviews the export documentation, risk reviews the workflow blueprint, and engineering reviews trial runs on generated test data. Optional red-team testing adds known attack scenarios. This page separates what is in place, what your team configures and what is still on the roadmap.
EU data practice
California data practice
Transit and storage
Assigned approvers
Third-party security audit
First in the certification plan; its target date is being finalized.
Security management
AI management system
Web accessibility
“In place” marks controls running today. “Roadmap” marks formal certifications Nxgyle is preparing for and does not hold yet; none is shown as held until it is formally awarded. Your team can ask security@nxgyle.com for the current position and supporting documents.
Where a status reads Roadmap, the work has started and nothing is claimed yet. Record it that way in your vendor file: every statement on this site describes what operates today, not what is planned.
SOC 2 Type II — target date: being finalized.
Until certification is awarded, your reviewers can work from three things instead.
- Your own compliance controls apply, since the workers sit on systems your team operates.
- Your audit lead can read the audit-trail specification ahead of time.
- Your security reviewer can request a sample export package with sensitive details removed.
What your security reviewer receives.
Your security reviewer gets a threat model with every export. The items below cover the platform Nxgyle operates, and supporting documents can be requested for your assessment.
- Data encrypted in transit and when stored
- Permissions set by role in the Studio and in each workspace
- Each export carries a data-flow diagram and threat model
- Platform activity is monitored and logged under a documented incident-response procedure
- Report vulnerabilities to security@nxgyle.com
Trials need no live records.
Teams design and trial workers in the Studio on generated test data, so evaluation needs no production records. In live operation your own systems host the software, with no Nxgyle cloud between your data and the worker.
- Trial runs can use generated test data alone; no design stage requires production records
- Every delivered worker is hosted in your environment
- Data we hold resides in Hyderabad, India and Herndon, VA
- Personal data retained or deleted on request, following GDPR and CCPA practice
- Sub-processor list available to your procurement team on request
Decisions your team can explain later.
Governance is part of how the team operates, not a clause in the contract. The Foundation keeps the rules, approvals and run traces behind each outcome on record.
- A blueprint each reviewer can read line by line
- Stated rules run as fixed checks where possible, so one input gives one verdict
- Approval checkpoints hold the worker until the assigned approver responds
- Every approval kept on record; a tamper-evident log is optional, and auditors can read its specification
- Personal data can be redacted before tool calls once you switch this on
Four mechanisms to put on the review plan.
Every statement on this site rests on one of these four. Your team can test each one in a live session with us, through documents your auditors request, or by reading a past trial run’s trace.
Rehearsal before reality
Nx·Studio generates a synthetic dataset shaped like each worker's process, and the worker goes through trial runs before it meets a live system. Your team can step through a trial or run it end to end, and approval checkpoints pause each run until the assigned approver answers. A simulation can run several workers together on an accelerated clock, with simplified stand-ins unless you pick the real workers. Optional red-team testing attacks the worker with known techniques and scores the result. With no production data involved, security can clear the evaluation on a written process description alone, without a data-sharing agreement.
How trials work in Nx·StudioRules you can rely on
When a rule is stated plainly, Nx·Studio's analyst agent encodes it as a fixed check; rules it cannot encode go on a list for your process owner. A fixed check involves no model, so the same facts always give the same outcome. Routine decisions without any written rule are the job of our Cognitive Engine, a product kept apart from Nx·Studio; your systems call it through the Cognitive Studio. Its only training material is outcomes confirmed by your own records or people, and a held-out exam must be passed before any rule takes effect.
Cognitive Engine basicsBlueprints you can read
Every digital worker follows a versioned blueprint, never a hidden chain of prompts. That blueprint records the steps, the decision rights at each approval checkpoint and the points where a case passes to a person. Your team can compare saved versions, branch them or merge them. Process owners read the same blueprint as swimlanes by team, person and system, and a Studio summary lists everything built. The blueprint is yours, along with the rest of the delivery.
Blueprints in governanceProof in every export
Inside every export sits a signed bill of materials: a manifest of its AI models, agents, connectors and libraries, plus an offline verifier for your engineers. The threat model and an EU AI Act Article 53 documentation template come with it. The Studio issues the itemized ownership report separately. In operation the worker draws nothing from Nxgyle, with no runtime, license check, meter or call home, so your team can test the absence of lock-in at handover.
Run the handover checkCheck the handover before you sign it off.
Every delivery comes with evidence your engineers can test: a signed bill of materials for the software and its AI components. Verification runs offline on your systems and never contacts Nxgyle. The Studio’s itemized ownership report completes the file, and a redacted example can be requested. The conclusion belongs to your reviewers.
Once the worker runs, Nxgyle is out of the loop: no runtime of ours to call, no license to check, no usage meter and no call home.
Your team can test the rules the same way. Pick a case in a live session, run it twice and confirm the stated rules reach the same decision both times.
- Signed bill of materials Lists each AI model, agent, connector and library, with an offline verifierincluded
- Threat model Threat analysis of the design, with a data-flow diagramincluded
- EU AI Act template A draft for the Act's documentation duties, not a conformity assessmentincluded
- Ownership report Inventory of the delivery, plus a PDF for stakeholdersvia Nx·Studio
Your team runs the checks and records the conclusion.
Write down who approves what before live operation.
Oversight here rests on written records rather than a dashboard: versioned, comparable and kept by your team.
The blueprint on the review plan
Each worker’s blueprint names its agents and their roles, connected systems, approval checkpoints, routing and decision rules. No part of that logic is hidden in prompt text or locked in a vendor platform. Engineering keeps it under version control, the risk owner approves the version that goes live, and auditors later compare the running worker with it.
Approvals on record
Every decision at an approval checkpoint goes into the audit trail with the approver’s name and a timestamp. Two more records are available, both off by default: a tamper-evident run log, and lineage tracing each data field to its source. A fixed rule check gives an identical result whenever the facts are identical.
Approval tooling your team runs
Approval checkpoints sit inside the worker and pause it until the approver acts. Every export with checkpoints adds a reviewer inbox application; your engineers link it to the worker, and Slack delivery is an optional export setting. Approvers come per checkpoint by role or by named team, and nobody can approve their own request. It is all code your organization owns, so the approval policy runs inside your own systems.
What your team shares, and how it is used.
Nx·Studio can generate realistic synthetic data shaped to each worker’s process, enough for previews, simulations and red-team tests with no production records involved. Any sample data uploaded by your team stays in your workspace and is visible only to its members.
Design material takes a separate path. When a design should reflect real volumes, process owners can share documents, process logs or sample data. Your team decides what to share, Nxgyle uses it only to design your workers, and data-processing terms are agreed before anything is transferred.
A written process description is enough to start, and it is the only document your team needs to share.
Which steps are fixed, which may vary, and who steps in.
The same case can get two different AI answers on two runs.
So your stated rules stay out of the model: they run as fixed checks inside the worker wherever possible, one result per set of facts. Each trial run’s trace records the result of every check. Routine decisions without a written rule go to our Cognitive Engine, which sits outside Nx·Studio workers and is reached through its Studio’s decision API. It learns only from verified business outcomes and may act only after passing an exam on held-back cases with no mistakes.
Any step that needs AI judgment can have a quality check scoring the answer against a threshold your team sets. Your team also chooses what a low score does: flag the answer, end the run or send the case to an approver. Flagging is the default, and at approval checkpoints the worker waits for the approver.
Your team decides who steps in, and when.
Six artifacts to hand to risk and audit.
Each item is redacted first and shared on request through security@nxgyle.com.
Redacted blueprint sample
A sample worker's swimlanes and export summary, for risk reviewers to study the behavior before anything runs.
Example trial-run report
Results of a trial run on generated test data, for procurement and risk to judge readiness.
A trimmed export for code review
A sample export's folder tree, README and test suite, for your engineers to judge code quality before the program starts.
Outline of the threat model
Scope and structure of each export's threat model, without configuration details.
The audit-trail specification
The events that get recorded, and the method an optional tamper-evident log uses to reveal later edits.
Ownership report from a sample
A sample export's inventory, the verifier's output and the signed bill of materials, for your reviewers to reach their own conclusion.
Your audit lead can check each worker’s intended behavior before live operation.
Three commitments your team can test.
Every pledge fits in a sentence and stays inside what the product can show, so your team can test all three.
Your team can design and trial a worker without production data.
No runtime from Nxgyle, no usage charges, nothing sent back to us.
If the engagement ends, your exported workers still run.
Each published figure comes with its measurement method. What we cannot yet measure honestly is not published.
The same rule covers external statistics: cited with source and date, or not at all. Delivery counts carry a short counting-method note and are rechecked before each publication, and any figure that fails a later check is withdrawn from every page.
Who owns uptime
Your team controls the availability of delivered workers, because they run on your infrastructure under your service levels. On our side, the Nxgyle platform is monitored under an incident-response procedure, and a public status page is on the roadmap.
Contacts by topic
- Security reports security@nxgyle.com
- Privacy requests privacy@nxgyle.com
- Accessibility accessibility@nxgyle.com