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.
Scope inference, extraction, retrieval and storage on infrastructure you control. Document and test any external connector, support channel or transfer before describing a workflow as zero-egress.
Workflows with local models, data and supporting services can continue offline. Live external email, calendars and other services need an approved connection or controlled import, with clear unavailable and pending states.
Map prompts, documents, indexes, logs and backups to their processing and storage locations. Local hosting supports control of location; access, retention and any transfers still need review.
Prepare and classify source records, preserve permissions and evaluate answers against the originals. Retrieval and model training are separate choices; agree data use and licences for each.
Compare hardware and licences alongside integration, power, administration, support, updates, evaluation and recovery. Measure cost at the required workload and quality before claiming savings.
Define who holds keys, who can administer the system and which actions need approval. Test denied requests, revoked access and audit records. Physical security, insider risk and incident response remain operational responsibilities.
Agree version selection, signed update procedures, rollback, data export and licence rights. Reassess requirements as software and obligations change; owning hardware does not remove maintenance or compliance work.
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.