PCI-DSS
The Payment Card Industry Data Security Standard governs how cardholder data is stored, processed and transmitted, and it makes the size of the audited environment a direct function of where that data can flow. Mickai keeps cardholder data on hardware the organisation owns, fully offline, so it is never transmitted to a cloud AI service and never enters a shared, multi-tenant environment. Because the data physically cannot leave the building, the standard's demands for access control, protecting stored data, restricting transmission and logging every access are enforced by architecture, and every touch of cardholder data is sealed to a post-quantum Open Audit Record.
PCI-DSS scope follows the data: every system that stores, processes or transmits cardholder data falls inside the cardholder data environment that must be secured and assessed, and every additional place the data can flow enlarges that scope. Sending cardholder data to a cloud AI service pulls that provider into scope, expands the environment across infrastructure you cannot inspect, and adds transmission paths that must be encrypted, monitored and segmented. The standard demands strict access control on a need-to-know basis, protection of stored cardholder data, restriction of transmission across open networks, and logging and monitoring of all access to cardholder data and network resources. Each of these is harder to evidence when the data and the model sit in a shared tenancy. Mickai keeps cardholder data on hardware the organisation owns, fully offline, so it is never transmitted to a third party and the cardholder data environment does not expand to a cloud provider. Access is enforced locally on a need-to-know basis, there is no open-network transmission to a shared service to protect, and every access to cardholder data is sealed to an immutable Open Audit Record that satisfies the logging and monitoring requirements by construction.
The 6 obligations this framework imposes, each met by construction on hardware you own and mapped to the subsystem that enforces it.
Scope Containment, No Cloud Cardholder Data Environment
Because cardholder data is processed on hardware you own and never transmitted to a cloud AI service, that provider is never pulled into the cardholder data environment and the assessed scope does not expand across infrastructure you cannot inspect. The environment that must be secured and audited contracts to systems the organisation controls end to end. There is no shared tenancy to bring into scope. Scope is contained by architecture rather than by network segmentation alone.
Access Control on a Need-to-Know Basis
Mickai gates every read and write of cardholder data behind hardware-attested identity and least-privilege clearance, satisfying the PCI-DSS requirement to restrict access on a need-to-know basis. Access can be scoped per role and descends to the record level, so no operator sees card data beyond their authority. Nothing is exposed to a shared cloud identity layer. Every access decision is made and enforced inside your perimeter.
Protecting Stored Cardholder Data
Stored cardholder data remains on hardware the organisation owns, under keys the organisation controls, so protection of stored data is enforced without handing the data or the keys to a third party. There is no vendor replica to protect and no shared storage tenancy to trust. Any change to stored data is sealed to the audit trail and attributable. The organisation retains full custody of the stored cardholder data environment.
Restricting Transmission Across Open Networks
Because cardholder data is processed in place on owned hardware, there is no transmission to an external AI service across an open network, which satisfies the transmission-restriction requirement by removing the exposure rather than encrypting around it. Card data never crosses the internet to a third party in the inference path. The transmission surface the assessor reviews contracts accordingly. Both the requirement and the risk are addressed by construction.
Logging and Monitoring of All Access
PCI-DSS requires tracking and monitoring of all access to cardholder data and network resources, and Mickai meets this by sealing every access to a post-quantum Open Audit Record with the actor, the data touched and the time. The trail is tamper-evident and reproducible for a qualified security assessor, held on hardware you own. There is no reliance on a vendor's logging tenancy. The logging and monitoring requirement is satisfied as a by-product of the work.
Anomaly and Fraud Surveillance In-House
Mickai screens transactions and card-data access for anomalies and fraud indicators entirely on owned hardware, so the detection logic and the cardholder data both stay inside your perimeter. No card data is shared with an external monitoring service, and the detection rules are never exposed to a third party. Suspicious activity is flagged with a sealed evidence trail. Surveillance strengthens the environment without adding a data-sharing arrangement.
The advantages hold across every framework, and they are architectural, not promotional. The third-party cloud-exposure vector is removed; your own physical, insider and compliance controls remain yours.
The data never leaves your hardware, so no third party and no cloud-provider employee ever sees it. What happens in the server room stays in the server room.
You own the compute and the capability, so the system runs independent of the internet and of any cloud vendor's pricing, terms, or availability.
The data never crosses a geographical or digital border because it never leaves the building, which removes the cross-border-transfer and third-party-processing friction of UK GDPR, Schrems II, and the sector rules. You keep your own obligations.
Fine-tune and run retrieval on your deepest archives to build a hyper-customised co-pilot, with no risk of your proprietary edge training a public model or leaking.
After the hardware and licence, queries cost essentially electricity. A capital asset you own and depreciate, instead of volatile per-token cloud bills.
There is no third-party cloud path, so no competitor and no vendor insider can scrape, intercept, or subpoena your prompts or your fine-tuned weights from the internet. The trust vault is closed by architecture.
You own the software snapshot on your own hardware, so a change to a cloud vendor's terms, a model deprecation, or an outage cannot reach you. The system stays predictable and auditable on-premise as the rules evolve.
How does on-premise AI keep cardholder data in scope control?
Mickai keeps cardholder data on hardware the organisation owns, fully offline, so it is never transmitted to a cloud AI service and never enters a shared environment. Because the data physically cannot leave the building, the cardholder data environment does not expand to a cloud provider, and PCI-DSS demands for access control, protecting stored data, restricting transmission and logging every access are enforced by architecture. Every touch of cardholder data is sealed to a post-quantum Open Audit Record.
Does using Mickai pull an AI provider into PCI scope?
No. Because cardholder data is processed on hardware you own and never transmitted to a cloud AI service, that provider is never pulled into the cardholder data environment and the assessed scope does not expand across infrastructure you cannot inspect. The environment that must be secured and audited contracts to systems the organisation controls end to end.
How does Mickai protect stored cardholder data?
Stored cardholder data remains on hardware the organisation owns, under keys the organisation controls, so protection of stored data is enforced without handing the data or the keys to a third party. There is no vendor replica to protect, any change to stored data is sealed to the audit trail and attributable, and the organisation retains full custody of the stored cardholder data environment.
How is the logging and monitoring requirement satisfied?
Mickai seals every access to cardholder data to a post-quantum Open Audit Record with the actor, the data touched and the time, which meets the PCI-DSS requirement to track and monitor all access as a by-product of the work. The trail is tamper-evident and reproducible for a qualified security assessor and held on hardware you own, with no reliance on a vendor's logging tenancy.
Can card-data fraud detection run without sharing data?
Yes. Mickai screens transactions and card-data access for anomalies and fraud indicators entirely on owned hardware, so the detection logic and the cardholder data both stay inside your perimeter. No card data is shared with an external monitoring service, and suspicious activity is flagged with a sealed evidence trail. Surveillance strengthens the environment without adding a data-sharing arrangement.
Is Mickai a cloud payment service?
No. Mickai is a Sovereign Intelligence Operating System acquired as an owned asset that runs on your own hardware, not a cloud service that handles card data on your behalf. The public cloud remains useful for non-regulated work; Mickai is the answer for the regulated cardholder-data boundary where the data cannot safely sit in a shared environment.
Bring PCI-DSS in-house.
Briefings are for organisations weighing a sovereign, on-premise deployment. Tell us about your estate and we will walk the obligations, the regulatory crosswalk and the deployment that fits.