Show your risk team the evidence, not a promise.
Give your reviewers what they will ask for. Before any digital worker from Nxgyle touches live cases, your risk, security and audit colleagues can read its blueprint and see it measured on sample data. If you enable it, the red-team module also tests the worker against common attack methods. This page lists the evidence, and what we do not claim yet.
EU personal-data rules
California consumer privacy
Data moving or stored
Review points in workflows
Audit of security controls
First certification planned — target date: being finalized.
Security program standard
Managing AI responsibly
Accessible interfaces
“In place”: operating today. “Roadmap”: certification by a third party that is in progress and not yet awarded. Nothing on this page presents a certification as held before the award. When your risk team asks for status and documents, point them to security@nxgyle.com.
Some tiles show Roadmap so your reviewers can separate current controls from planned certifications. Claims across this site carry the same labels.
SOC 2 Type II — target date: being finalized.
Until then, you can show your reviewers the following.
- The software runs in your environment, inside the compliance framework you already operate.
- Auditors may read the audit-trail specification.
- Redacted sample files can be shared with your IT security team on request.
What your security team will check.
Each delivery includes a security analysis for your IT security team (a threat model). They can compare platform controls, data handling and deployment duties with your company's requirements.
- Encryption for data on the move and for stored data
- Access to the Studio and its workspaces by role
- A threat model and data-flow diagram inside each delivery
- An incident-response process backed by platform monitoring and logs
- A published way to report security flaws to us
Evaluate on sample data.
Each worker can be measured on data the Studio generates, so no customer or supplier records are needed. After delivery, the software runs in your own hosting environment and no Nxgyle cloud is involved.
- Test runs can use synthetic data only; designing or measuring a worker needs no production records
- Delivered software runs on infrastructure your IT team selects
- Two operating locations hold data: Herndon, VA and Hyderabad, India
- GDPR- and CCPA-informed handling of personal data; retention and deletion handled on request
- Sub-processors disclosed on request
Show auditors how each decision was made.
Your auditors will test how decisions are governed, not just how they perform. The Foundation keeps a run history showing which rule, reviewer or AI step produced each outcome.
- Blueprints anyone can read, instead of “the model decided”
- Written rules become rule-based steps wherever possible, so identical inputs give identical results; AI steps need their own evaluation
- Review points where the worker waits for a person's decision
- Every approval on record; switch on the tamper-evident run log and auditors may request its specification
- Optional personal-data redaction when the worker calls your systems, off by default
What to test, mechanism by mechanism.
Share these with your risk and IT colleagues to assess how a worker behaves and what each delivery contains. Ask for the documents and test results that match your scope.
Rehearsal before reality
For each worker, the Studio generates synthetic data shaped like its process, such as invoices or claims, so behavior is measured before a live system is ever connected. Exercise one step on its own or the complete process, and see each run pause at review points before resuming. Multiple workers can share one test, at accelerated time if you like, either as simplified stand-ins or as the actual workers. If you switch it on, the red-team module attacks a worker with known techniques. None of this needs production data, though your security colleagues will still want to review the evaluation scope and anything shared.
Evaluate in Nx·StudioRules you can rely on
Nx·Studio's AI analyst converts each written rule, such as an approval limit, into a rule-based step where it can, and lists the ones it could not convert. Those steps never call an AI model, so one set of inputs always yields one verdict. Decisions that follow unwritten patterns are the Cognitive Engine's job; it runs apart from Nx·Studio and connects through its own Studio. Its rules are learned from results your staff have confirmed, and each must pass a test on unseen examples before deciding anything.
Assess the Cognitive EngineBlueprints you can read
Every digital worker comes with a versioned blueprint in place of a stack of prompts. It shows the steps, who reviews what, and where cases pass to a person. Saving a change produces a new version to compare, branch or merge. Your teams see it as lanes per team, person and system, with a Studio summary of exactly what was built. The blueprint, like everything generated, belongs to you.
Governance in detailProof in every export
Each delivery includes a signed inventory of everything inside the software (a signed bill of materials) and a verifier your IT team runs offline. Alongside sit a security analysis for your IT security team and an EU AI Act template that your compliance team can complete. The Studio issues a separate itemized ownership report. Nothing in a worker depends on Nxgyle at run time: no runtime, meter, license check or call-home code. Your IT team can test the “no lock-in” claim itself.
Inspect the evidenceYour IT team can test it without us.
Each delivery carries evidence that stands on its own. Its signed inventory covers the software, the AI models and the agents it contains. Your IT team can confirm the signature on an offline machine without contacting us. Separately, the Studio provides an ownership report listing every item. Ask for a redacted sample, and make the assessment yourself.
A delivered worker needs nothing from Nxgyle to run. It contains none of our runtime code, performs no license check, keeps no meter and opens no connection to us.
Rule behavior is shown live as well: process the same case twice in a session with us and confirm the written rules return an identical answer.
- Signed bill of materials Covers the software and its AI components, signed, with an offline verifierin each export
- Threat model A security analysis plus data-flow diagram, for your IT security teamin each export
- AI Act documentation template A starting point your compliance team completes, not a conformity assessmentin each export
- Ownership report Everything delivered, item by item, with a PDF summaryStudio report
Your hardware, your verification, your conclusion.
Approve each worker only after reading its plan.
There is no dashboard hiding a black box. Governance takes the form of documents your reviewers can read, compare across versions and file.
A blueprint all reviewers share
Each worker is described by a readable, versioned blueprint covering agents and their roles, connections to your systems, review points, routing and decision logic. Nothing is tucked into prompts or locked inside another company’s runtime. Your IT team versions and compares it like code, governance reads it before production use, and audit uses it as the reference afterwards.
Who approved what, and when
Each approval is written to the audit trail, naming the reviewer and recording the time. Two further records stay off unless you enable them: a tamper-evident run log, plus a record of where each data field originated. Rule-based steps give the same verdict whenever the inputs match.
The reviewer app ships with the worker
At a review point the worker waits until a person decides. Deliveries with review points include the inbox application reviewers use; your IT team connects the two, and Slack alerts are an add-on. Each review point names a role or team as its reviewer. Your approval policy is enforced by code you own, not by a setting on our servers.
What an evaluation needs from your data.
The Studio generates synthetic data per worker, matched to its process, so previews, simulations and red-team tests need no production records. Sample data your team uploads is visible only to members of your workspace.
Design inputs are handled under different terms. Documents, process logs or sample data help a design reflect your real volumes, but sharing them is your decision. Their only use is designing your workers, and no transfer happens until a data-processing agreement is in place.
An evaluation that starts from a plain description of the process keeps production data out entirely.
Separate the repeatable from the variable, and name the decider.
Expect AI-generated answers to vary between runs.
Your written rules therefore never rely on AI judgment. Where possible they run as rule-based steps inside the worker and return one answer for one input. Each step's result appears in the test-run record for later review. Repetitive decisions without written rules go to our Cognitive Engine, a product kept separate from Nx·Studio workers, with its own Studio. Its rules come only from confirmed outcomes, and no rule acts until it has been examined on held-back cases and passed.
An AI step can carry a quality check that scores each answer. You choose the threshold and the consequence of a low score: raise a flag, stop the run, or send the case elsewhere, for example to a person. By default the check only flags. At a review point, nothing proceeds until a person decides.
A person steps in where you decide.
Documents to hand your auditors.
Every document is redacted first and sent on request; write to security@nxgyle.com.
A sample worker's blueprint
The swimlane view and export summary your governance reviewers would read before approving production use.
Report on a synthetic test run
What a test run on synthetic data measured, in a form your procurement review can file.
Sample code for IT review
The file layout, documentation and tests of one delivery, for your IT team to judge what they would maintain.
Threat-model coverage
Coverage of the security analysis shipped with each delivery, minus configuration details.
The audit-trail specification
The recorded event types, plus how the optional tamper-evident log shows any change made afterwards.
Handover report, sample
Item by item, with the signed bill of materials and the verifier's result from one sample delivery.
Your reviewers can judge a worker’s intended behavior before you approve it.
Commitments narrow enough to test.
Every pledge is a single sentence and covers only what the platform can show. For your evaluation, a testable promise is worth more than a broad one.
Production data is optional for design and testing.
No Nxgyle runtime, no fee per decision, no link back to us.
An exported worker keeps working after the engagement closes.
Distinguish catalog coverage from measured outcomes. Validate results in your environment.
Catalog counts describe published records, not customer deployments. Simulated results and third-party forecasts retain their context and attribution. Ask for supporting evidence and test its relevance to your workload before committing budget.
Availability
Delivered software runs on infrastructure your IT team selects, which puts availability under your own service levels. Services Nxgyle hosts follow an incident-response plan with monitoring; a public status page for them is on our roadmap.
Reach the right contact
- Security & disclosure security@nxgyle.com
- Privacy & data rights privacy@nxgyle.com
- Accessibility accessibility@nxgyle.com