Security & Compliance
Trust Center
Last verified: October 22, 2026
BI Pixie is operated by DataChant Consulting LLC, an Illinois limited liability company. “BI Pixie” is the company’s registered assumed name. This page summarizes our security, privacy, and compliance posture for the four deployment models we support. It is published as a self-serve resource for customer security and procurement teams and is consistent with our Privacy Policy, Terms of Service, and the Microsoft Fabric Workload Vendor Attestation.
The trust boundary (who can access customer data and where it lives) differs significantly between deployment models. The comparison table below is the fastest way to identify which model applies to you and what controls are in place. Each model has its own detailed section further down.
The Microsoft Entra permissions BI Pixie requests in your own tenant are listed on a separate page for each hosted deployment, with the reason each permission is needed and what BI Pixie reads and writes under it: BI Pixie Cloud and BI Pixie Workload in Microsoft Fabric. Both are written for an administrator or a security reviewer who has no BI Pixie account, so they can be forwarded to whoever approves access.
For security or procurement questions not answered here, contact support@bipixie.com.
At a Glance
BI Pixie’s deployment models differ along two dimensions: who operates the platform, and where your data lives.
These are two separate choices, and most organizations do not answer them the same way. A customer can run BI Pixie on Azure inside their own subscription and still use BI Pixie Cloud for AI Readiness. Read one row from each table below, then see “Combining deployments” for what that combination means.
Who operates the platform
The platform is the software that adds Pixies to your reports, scores your semantic models, and serves the BI Pixie Dashboard.
| Deployment | Operated by | Our role | AI Readiness | Authoritative reference |
|---|---|---|---|---|
| BI Pixie Cloud | BI Pixie | Data processor | Available | Privacy §3-9, Terms §6 |
| BI Pixie Workload in Microsoft Fabric | BI Pixie, running inside your Fabric tenant | Software vendor, and data processor for raw telemetry | Available | BI Pixie Workload attestation |
| BI Pixie on Azure (managed app) | You | Software vendor only | Not available | Privacy §10.1 |
| BI Pixie on Power Platform | You | Software vendor only | Not available | Privacy §10.2 |
The AI Readiness column is the one that changes your trust position, because it is the reason a customer who already runs BI Pixie inside their own tenant would add a BI Pixie-operated deployment alongside it.
Where each kind of data lives
Storage is a separate decision from the table above. Customers on BI Pixie Cloud or the Workload may keep their telemetry in their own storage instead of ours.
| Data | BI Pixie storage (default) | Your Azure storage | Your OneLake |
|---|---|---|---|
| Telemetry events | Our Azure, in the region assigned to your account | Your ADLS Gen2 account | Your Fabric capacity |
| AI Readiness assessment results | Our Azure | Not written to our storage, and not written to yours: BI Pixie does not write assessment results into your ADLS Gen2 account. You see the full result when the assessment finishes, and there is nothing kept for you to reopen later. We record the score and the number of findings, and we do not record the findings themselves. | Your Fabric capacity, in the same place as your telemetry, and you can reopen the full result there. We record the score and the number of findings so you can track them over time, and we do not record the findings themselves. |
| A semantic model you change with AI Readiness | BI Pixie keeps no copy of the semantic model definition. If you ask BI Pixie support for help, support can turn on a copy for your account: BI Pixie then keeps the definition from before and after each change in our Azure storage, in the region assigned to your account, and deletes each copy after 30 days. | BI Pixie keeps no copy. | BI Pixie keeps no copy. |
| A report you add Pixies to | With Auto-Save to Power BI, BI Pixie keeps no copy of the report and semantic model definition files that it wrote. With Download & Publish, BI Pixie holds the files in our Azure storage for your download and deletes them after 30 days. If you ask BI Pixie support for help with a report, support can turn on a copy for your account: each time you add, update, or remove Pixies, BI Pixie then keeps a copy of the files that it wrote, in the region assigned to your account, and deletes each copy after 30 days. | With Auto-Save to Power BI, BI Pixie keeps no copy. With Download & Publish, BI Pixie holds the files in our Azure storage for your download and deletes them after one day. | With Auto-Save to Power BI, BI Pixie keeps no copy. With Download & Publish, BI Pixie holds the files in our Azure storage for your download and deletes them after one day. |
| BI Pixie Dashboard items | Not applicable | Not applicable | Your Fabric capacity |
| Our access to that store | Operations and support only, per the Privacy Policy | Write, to deliver your telemetry. Read only if you grant it, through a credential you can revoke. No delete or retention permission unless you choose to grant that too. | Write, to deliver your telemetry into your lakehouse. Read only if you grant it. No delete or retention permission. |
When you change a semantic model with AI Readiness, BI Pixie keeps no copy of it. Each time you apply an AI Readiness change to a semantic model, BI Pixie applies the change and keeps no copy of the semantic model definition from before or after it. If you ask BI Pixie support for help, support can turn on a copy for your account, so that support can see what a change did. With that copy turned on, BI Pixie keeps the semantic model definition from before and after each change in our Azure storage, in the region assigned to your account, and deletes both copies after 30 days. If you have declared your own Azure storage or your own OneLake, BI Pixie keeps no copy, even when support has turned the copy on.
When you add, update, or remove Pixies, BI Pixie holds the report and semantic model definition files it wrote only for your download, or when support turns on a copy. When you use Auto-Save to Power BI, each time you add Pixies to a report, update its Pixies, or remove them, BI Pixie keeps no copy of the report and semantic model definition files that it wrote. With Download & Publish, BI Pixie holds those files in our Azure storage for your download, in the region assigned to your account, and deletes them after 30 days. If you ask BI Pixie support for help with a report, support can turn on a copy for your account. With that copy turned on, BI Pixie keeps a copy of the files that it wrote each time you add, update, or remove Pixies, and deletes each copy after 30 days. If you have declared your own Azure storage or your own OneLake, BI Pixie never keeps that copy, and what BI Pixie holds depends on the delivery method you select. With Auto-Save to Power BI, BI Pixie keeps no copy. With Download & Publish, BI Pixie holds the files in our Azure storage for your download and deletes them after one day.
What the telemetry contains does not vary with where it is stored. BI Pixie collects anonymized usage events and no business data from inside your reports. End-user identity and filtered values are off by default, and enabling either requires an explicit opt-in. Raw IP addresses are never retained; they are hashed at ingestion. See Privacy §3-4. We do not mine your telemetry, train models on it, or use it for advertising or profiling.
Wherever your data lives, scoring a semantic model reads its definition through BI Pixie’s service. Where you have chosen your own storage, the assessment result is not written to ours. Those are two different statements, and both are true: the assessment result stays out of our storage, and we do process the semantic model definition in order to score it.
BI Pixie hands a finished AI Readiness result back to you through our own storage. The assessment runs in the Azure region assigned to your account, and BI Pixie writes the finished result to a job record in our storage so that the portal or the Fabric workload can collect it. For an account that has declared its own storage, BI Pixie splits that job record in two. The copy carrying your findings is deleted within one day. The copy that remains holds the score, the number of findings, and the names of the semantic model and its workspace. For those accounts that handover is the one point at which the findings rest in our storage, and they are not kept there.
Combining deployments
The two tables are independent, so a customer can appear in both. The combination that needs the clearest answer is a customer who operates BI Pixie themselves and adds a BI Pixie-operated deployment for AI Readiness.
In that case the “we have no access to your data” position of the self-operated deployments applies to that deployment only. The AI Readiness service reads semantic model definitions from your Power BI tenant under your own user’s permissions, and where you have declared your own storage it will not write the finished assessment into ours, or keep a copy of a semantic model that you change. Read the Where each kind of data lives table for the deployment you added, not the one you started with.
Architecture diagrams
Each diagram is a one-page PDF. In it you can see where every component runs, how usage events travel from your reports, and where those events are stored. You can forward a diagram to whoever reviews architecture or security for your organization.
| Diagram | What you see in the diagram |
|---|---|
| BI Pixie Cloud | BI Pixie Cloud with BI Pixie storage. No Microsoft Fabric capacity is needed. |
| BI Pixie Workload in Microsoft Fabric | The Workload with BI Pixie storage, and the optional delivery of your telemetry to your own OneLake. |
| Your Azure storage with the Workload | Telemetry collected and stored in your own Azure subscription, with the Workload in Microsoft Fabric. |
| Your Azure storage with BI Pixie Cloud | Telemetry collected and stored in your own Azure subscription, with BI Pixie Cloud. |
Platform controls
| Control | Self-operated (Azure, Power Platform) | BI Pixie-operated (Cloud, Workload) |
|---|---|---|
| Encryption | Your own Azure-managed or Power Platform encryption | TLS 1.2 or above in transit, AES-256 at rest, Azure-managed |
| Sign-in | No BI Pixie sign-in. The only relevant login is the Power BI service, using your tenant’s Entra ID, to view the BI Pixie Dashboard. | Your Entra ID. The Workload inherits Conditional Access through the Fabric host. |
| Service-to-service access | Connection strings by default, kept in the app settings inside your subscription. You can swap to managed identity and access controls under your tenant policies. | Per-customer access controls using a managed identity, plus customer-scoped tokens that are expirable and revocable for direct dashboard access. |
BI Pixie on Azure
BI Pixie is deployed entirely within your own Azure subscription as an Azure Managed App. All telemetry data, configuration, and identity remain inside your Azure tenant. BI Pixie ships the deployment template; you operate the deployed resources.
Trust boundary
Your Azure subscription. The resources BI Pixie deploys (Function Apps, Storage Accounts, Event Hub, etc.) are created in your tenant under your billing, your IAM, and your security policies. Service-to-service secrets are stored as connection strings in the app settings of the deployed Function Apps. The deployment does not yet offer a Key Vault of your own for these secrets. We have no plane of access to any of these resources. Per Privacy Policy §10.1, we act as neither a data controller nor a data processor for any data your deployment collects.
That statement covers this deployment on its own. If you also use BI Pixie Cloud or the BI Pixie Workload for AI Readiness, the trust position for that second deployment is described in Where each kind of data lives above, and it is not the same. See “Combining deployments”.
Security inheritance
All controls of your Azure tenant can be applied to the deployment: Microsoft Defender for Cloud, Entra Conditional Access (including MFA, compliant-device, named-location, sign-in risk, session controls), Azure Policy, Private Endpoints, audit log export to your SIEM, and any other Azure-native or third-party tooling you have in place. Encryption at rest and in transit is provided by the Azure platform. By default, data at rest is encrypted with Microsoft-managed keys. From version 1.1.0 of the deployment template, a new deployment can encrypt its storage with a key you hold in your own Key Vault, and can optionally do the same for Event Hubs on the Premium tier. Revoking that key stops new events from being recorded. The key does not limit what the deployed Function Apps can read while the key is available. See Encryption with your own key.
Data residency
You select the Azure regions for deployment. Data never leaves the regions you select. This is governed entirely by your tenant configuration; BI Pixie does not introduce a residency boundary of its own.
Updates and lifecycle
Software updates are delivered through the Azure Managed App update mechanism on a cadence you approve. The Managed App publisher (DataChant) does not retain runtime access to the deployment; updates are an opt-in publisher offer that you accept through the Azure portal.
BI Pixie Desktop
Self-hosted customers add Pixies to their reports with BI Pixie Desktop (bi-pixie.exe), a
Windows desktop application that runs in your environment. You select which reports and
semantic models it adds Pixies to. You can either bring local copies of their definition files to the application,
or let the application load them directly from Power BI using your az login credentials.
Definition files flow only between your machine and your Power BI environment; report
content and semantic-model definitions never pass through the BI Pixie cloud. The executable
is first-party code with no open-source or third-party runtime dependencies, which reduces
the supply-chain surface that customers must vet.
The only network call BI Pixie Desktop makes to the BI Pixie cloud is a license check. It transmits your account email, your license key, and an inventory of the reports it added Pixies to. That inventory lists each report by its workspace name and report name, along with the number of pages it contains. No report content, no telemetry, and no end-user data is sent. New versions are distributed as installer downloads through the self-hosted user guide; you choose when to install them.
Compliance
Compliance posture is governed by your Azure tenant. BI Pixie inherits Microsoft Azure platform certifications relevant to your subscription (ISO 27001, ISO 27018, SOC 1/2/3, HIPAA BAA, FedRAMP, EU Model Clauses, etc.). DataChant does not make compliance claims about data in this model because the data is never in DataChant’s possession.
Reference: Deploy on Azure · Privacy Policy §10.1
BI Pixie on Power Platform
BI Pixie is deployed inside your Microsoft Power Platform environment. All telemetry data, configuration, and identity remain inside your Power Platform tenant. The trust posture is the same as BI Pixie on Azure, with the deployment running on Microsoft Power Platform rather than on Azure directly.
Trust boundary
Your Power Platform environment. The connectors, flows, and storage that BI Pixie creates exist inside your environment under your governance. We have no plane of access. Per Privacy Policy §10.2, we are neither a data controller nor a data processor for data collected by the deployment.
Security inheritance
All controls of your Power Platform environment apply: Dataverse security roles, environment-level data loss prevention (DLP) policies, Entra Conditional Access on the underlying tenant, customer-managed keys (where supported by your Power Platform license), and Microsoft 365 audit log integration. Encryption at rest and in transit is provided by Microsoft Power Platform.
Data residency
Determined by the geography of your Power Platform environment. Microsoft’s Power Platform regional model governs where data is stored and processed; BI Pixie does not introduce additional regional movement.
Instrumentation client
This is the same as BI Pixie on Azure: report instrumentation is performed by the BI Pixie Instrumentation Windows desktop application running on the report author’s machine, with no open-source or third-party runtime dependencies and a license check limited to your account email, your license key, and an inventory of the reports you instrumented. See the BI Pixie on Azure section for the full description.
Compliance
Inherits Microsoft Power Platform compliance attestations (ISO 27001, ISO 27018, SOC 1/2/3, HIPAA, GDPR, EU Model Clauses, etc.) per your tenant configuration. As with BI Pixie on Azure, DataChant does not make compliance claims about data in this model because the data is not in DataChant’s possession.
Reference: Deploy on Power Platform · Privacy Policy §10.2
BI Pixie Cloud
BI Pixie operates the platform on Microsoft Azure on your behalf. You are the data controller; BI Pixie is the data processor for end-user telemetry data. This is the deployment model where the most detailed controls apply and where our public commitments are most extensive.
Trust boundary
BI Pixie’s Azure tenant, in one of two production regions: East US 2 or West Europe. Further geographies, including India and South Asia, are provisioned on customer request within 30 business days. New customers are placed in the region closest to their Power BI home region by default; Enterprise tier customers may select a specific region to meet data-sovereignty requirements. Each customer is provisioned an isolated container in Azure Data Lake Storage Gen2. Cross-customer access is not left to application logic. It is enforced by Azure’s identity platform, through per-customer RBAC on the storage account itself. See Privacy Policy §6.2 for the data-isolation contract.
Encryption
All communication uses HTTPS with TLS 1.2 or higher. Data at rest is encrypted with AES-256 using Azure-managed keys. Encryption is enforced at the storage-account level; tracking-pixel HTTP requests, control-plane API calls, and dashboard reads are all TLS-only.
Identity and access
Customer administrators authenticate with Microsoft Entra ID. Internal service-to-service calls use Managed Identity (no shared connection strings); cross-service access is governed by Entra application roles. All admin-level mutations emit structured audit logs aligned with SOC 2 CC7.2.
Access to the customer’s dedicated storage container uses two mechanisms, each scoped to a distinct consumer:
- Per-customer RBAC. Used by the BI Pixie backend and the BI Pixie Portal to act on the customer’s behalf, bounded to two scopes: (a) the customer’s dedicated storage container in BI Pixie Cloud, accessed via the platform’s Managed Identity; and (b) the report and semantic-model definitions in Power BI Service, accessed under the user’s own Power BI workspace roles. The platform reads and writes only what the signed-in user is already authorized to access in their Power BI tenant.
- Customer-scoped SAS tokens. Issued to the BI Pixie Dashboard that customers install in their Power BI tenant. The dashboard connects directly to the customer’s container in BI Pixie Cloud using a scoped, expirable, revocable SAS token; no BI Pixie service is in that request path.
Enterprise tier: customers may issue separate RBAC assignments and separate SAS tokens to different teams and users within their organization, supporting least-privilege separation.
Data residency
BI Pixie Cloud operates in two production Azure regions: East US 2 and West Europe. Further geographies, including India and South Asia, are provisioned on customer request within 30 business days. New customers are placed in the region closest to their Power BI home region by default. Enterprise tier customers may select a specific region to meet data-sovereignty requirements (for example, an EU-based customer may choose West Europe to ensure telemetry remains within the EU/EEA). Once assigned, telemetry data is stored exclusively in that region; cross-border movement does not occur without an explicit migration request. See Privacy Policy §6.3.
Data we collect (and what we do not)
What we collect is described in detail in Privacy Policy §3 and is governed by an off-by-default privacy model (Privacy Policy §4): user identity capture, filtered values, and IP retention are all disabled unless you explicitly enable them. We also do not mine, analyze, or train AI/ML models on customer telemetry data, and we do not use it for advertising, profiling, or behavioral targeting (Privacy Policy §5.2).
Portal activity. For each signed-in member of your account, BI Pixie records the days they open the portal and the names of the portal pages they open. It is used only to improve BI Pixie. It records no IP address, device, browser or page content, uses no cookies or third-party analytics for it, and keeps it for 180 days (Privacy Policy §3.8).
Retention and deletion
Retention is plan-controlled and self-service. Maximum retention by tier: Free 30 days, Standard 30 days, Pro 1 year, Enterprise 3 years (see Privacy Policy §8). Events past your retention window are deleted daily. BI Pixie keeps no copy of a semantic model you change with AI Readiness, or of the files it writes when you add, update, or remove Pixies, unless BI Pixie support has turned a copy on for your account to help you. BI Pixie deletes such a copy after 30 days, whatever your plan, and deletes the files it holds for a Download & Publish after 30 days as well. Account-level deletion is supported on request; backup copies are retained briefly per Terms §7. End-user-level deletion (for GDPR DSARs) is supported via the Data Management view in the BI Pixie Portal; see the Data Management user guide.
Portal activity is kept for 180 days, and is deleted at once when a member is removed or the account is deleted.
The record of which AI app made each query through the BI Pixie connector in Claude is kept for 180 days, deleted daily after that, and deleted at once when the account is deleted.
Compliance
We implement SOC 2-aligned controls in the Security and Confidentiality trust service categories. CC7.2 (system monitoring) is implemented per our audit-logging architecture. DataChant has not engaged a third-party auditor for SOC 2 Type II at this time and will reassess as customer requirements warrant. We inherit Microsoft Azure’s compliance posture (ISO 27001, ISO 27018, SOC 1/2/3, HIPAA BAA, FedRAMP, EU Model Clauses, GDPR DPA) for the underlying platform. GDPR data subject rights are supported per Privacy Policy §11.3; CCPA rights per §11.4.
Reference: Privacy Policy · Terms of Service · Data Processing Agreement · Cloud FAQ
BI Pixie Workload in Microsoft Fabric
BI Pixie ships as a native Microsoft Fabric workload, published through the Fabric Workload Hub. The workload code is hosted by BI Pixie (frontend rendered as an iFrame inside the Fabric portal; backend in BI Pixie’s Azure tenant); the BI Pixie Dashboard items it produces (Lakehouse, Semantic Model, Report) live in your Fabric tenant; and raw telemetry events ingest to vendor-managed Azure storage in one of BI Pixie’s production regions. This is the architecture summarized in our Microsoft Fabric Vendor Attestation.
Trust boundary
The workload has three surfaces. (1) The workload code runs in BI Pixie’s hosting: the frontend is served from BI Pixie’s infrastructure and rendered as an iFrame inside the Fabric portal, and the backend runs in BI Pixie’s Azure tenant. (2) The BI Pixie items in your workspaces, including the BI Pixie Dashboard’s native Fabric items (Lakehouse, Semantic Model, Report), live in your Fabric tenant under Fabric workspace RBAC and Microsoft Entra Conditional Access; once installed, BI Pixie has no plane of access to these items (analogous to a Power BI template app installed in your tenant). (3) Raw telemetry events from instrumented Power BI reports ingest to vendor-managed Azure Data Lake Storage Gen2 in per-customer isolated containers, in one of BI Pixie’s two production regions: East US 2 or West Europe, or in a further geography provisioned on request. New customers are placed in the region closest to the Fabric capacity assigned to the first workspace from which the customer created the BI Pixie Workload item; Enterprise tier customers may select a specific region for vendor-managed storage to meet data-sovereignty requirements. The BI Pixie Cloud isolation and encryption commitments apply to this storage.
Identity and Conditional Access
The workload uses Microsoft Entra ID exclusively. Frontend tokens are acquired through the Fabric Workload Client SDK and exchanged via the standard On-Behalf-Of (OBO) flow against Entra. The workload frontend contains no MSAL library, no third-party cookies, and no custom OAuth flows; the backend OBO exchange uses Microsoft’s standard MSAL library against the Entra token endpoint. Because every token operation goes through Entra, the Conditional Access policies your tenant applies (MFA, compliant-device, named-location, sign-in risk, session controls) are evaluated at session acquisition and at each OBO exchange. See Attestation §2.1 and §2.3.
Activity in BI Pixie. When a member of your account opens BI Pixie in Microsoft Fabric, BI Pixie records the day and the names of the BI Pixie views they open. It is used only to improve BI Pixie. It records nothing about your Fabric workspaces, items or data, and nothing about the other Fabric pages a person uses (Privacy Policy §3.8).
Data storage
Dashboard semantic model and report items live in your Fabric workspace per Microsoft’s standard storage model for Fabric items. A per-customer per-workspace Lakehouse provides a OneLake shortcut to your telemetry for queryability inside Fabric. The item-definition JSON, which enables automatic provisioning of the BI Pixie Dashboard’s Fabric items into your workspace, contains only scope and tenant pointers (never the full tracking configuration) and is stored via Fabric’s control-plane item-definition API. Raw telemetry events at rest are documented in Attestation §2.2, including why the vendor-managed storage is used for the ingest path.
Storage access
Access to the customer’s dedicated vendor-managed container uses two mechanisms, each scoped to a distinct consumer:
- Per-customer RBAC. Used by the BI Pixie backend to act on the customer’s behalf when serving requests from the workload UI inside the Fabric portal, bounded to two scopes: (a) the customer’s dedicated container in the vendor-managed storage, accessed via the backend’s Managed Identity; and (b) the report and semantic-model definitions in Power BI Service, accessed under the user’s own Power BI workspace roles via the standard On-Behalf-Of flow. The backend reads and writes only what the signed-in user is already authorized to access in their Power BI tenant.
- Customer-scoped SAS tokens. Issued to the BI Pixie Dashboard items that are auto-provisioned in your Fabric workspace when you create a BI Pixie item. The dashboard connects directly to the customer’s container in the vendor-managed storage using a scoped, expirable, revocable SAS token; no BI Pixie service is in that request path.
Enterprise tier: customers may issue separate RBAC assignments and separate SAS tokens to different teams and users within their organization, supporting least-privilege separation.
Admin Monitoring
Admin Monitoring is set up by an admin of your BI Pixie account for one Fabric workspace, and its notebooks run once a day on your own Fabric capacity. They read the Power BI activity log (the first refresh reaches back 28 days), the inventory of workspaces, semantic models, reports and data sources with who has access to each, and, when it is turned on, DAX query durations from Workspace Monitoring or Azure Log Analytics. All of it is kept in that workspace’s Lakehouse, where everyone with access to the workspace can read it, and none of it is stored by BI Pixie. BI Pixie does not delete it on a schedule: it stays until you delete it, and turning off or removing Admin Monitoring leaves it in place.
User names are hidden by default. When you hide user names in Admin Monitoring, BI Pixie replaces each person’s name with a masked ID before anything is written to your workspace. To do that, the notebooks in your workspace send BI Pixie a one-way hash of each name, never the name itself. BI Pixie uses the hashes only to compute the masked IDs and never stores them, and the key that computes the masked IDs never leaves BI Pixie.
The data is read with a Fabric administrator’s own sign-in, or with a service principal whose secret stays in your Azure Key Vault and that uses the read-only admin API tenant settings. The full list of data and permissions is in the Data Inventory.
B2B and cross-tenant collaboration
B2B guest users in a Fabric workspace authenticate exactly as native users. The OBO token reflects the guest user’s home tenant; Fabric workspace RBAC governs whether they see the BI Pixie item. Per-license RBAC inside the BI Pixie data plane is granted to the AAD object IDs of users your admin authorizes, so guests gain access through the same flow as primary users. See Attestation §2.5.
Retention and deletion
Retention is plan-controlled and self-service. Maximum retention by tier: Free 30 days, Standard 30 days, Pro 1 year, Enterprise 3 years (see Privacy Policy §8). Telemetry events in the vendor-managed storage are automatically deleted daily once they exceed your retention window. BI Pixie keeps no copy of a semantic model you change with AI Readiness, or of the files it writes when you add, update, or remove Pixies, unless BI Pixie support has turned a copy on for your account to help you. BI Pixie deletes such a copy after 30 days, whatever your plan, and deletes the files it holds for a Download & Publish after 30 days as well. Dashboard and report items live in OneLake under your Fabric tenant and remain under your control; BI Pixie does not initiate deletion of those items. End-user-level deletion (for GDPR DSARs) is supported via the Data Management view in the BI Pixie Portal; see the Data Management user guide.
Activity in BI Pixie is kept for 180 days, and is deleted at once when a member is removed or the account is deleted.
Business continuity
Customer-portal monitoring and diagnostics are surfaced for the workload variant. BCDR plans and Service Health and Availability are documented in the Attestation under §2.6 and §5.3.
Compliance and certification
BI Pixie implements SOC 2-aligned controls in the Security and Confidentiality trust service categories (Attestation §4.4). The workload is published per the Microsoft Fabric Workload Hub vendor attestation requirements; the full attestation document is the authoritative source.
Reference: Microsoft Fabric Workload Vendor Attestation (full document) · BI Pixie Workload FAQ: Data and Privacy
Customer-Owned Storage
Customers on BI Pixie Cloud or the BI Pixie Workload may keep their telemetry in their own storage rather than ours. This is a storage decision, not a deployment change: BI Pixie still operates the platform, and the Who operates the platform table above still describes our role. What changes is where your data lives and what we are able to do to it.
Two destinations are supported: your own Azure Data Lake Storage Gen2 account, and your own OneLake in Microsoft Fabric.
What we can do to your storage
Two kinds of access are worth separating, because they are granted differently.
Writing your telemetry is what delivery means. BI Pixie writes your events into the store you chose, and that is the whole purpose of the arrangement.
Reading your telemetry is optional and is yours to grant. Without it, the self-service Data Management tools and the Event Viewer do not work over your own store, and we never read your data. See Privacy Policy §2.3 for the same statement in the policy.
Deleting your telemetry is something we cannot do. We hold no delete or retention permission, so we cannot remove your data and we cannot apply a lifecycle policy to it.
There is one exception, and it is one you choose. On your own Azure storage you may additionally grant BI Pixie delete permission so that in-product deletion works for you, for example to erase one end user’s data for a GDPR request. If you do not grant it, deletion in the product is unavailable rather than silently failing. On your own OneLake we never hold it at all, and you manage deletion yourself in your lakehouse.
The credential, and how you revoke it
For your own Azure storage you choose the mechanism:
| Mechanism | What it is | How you revoke it |
|---|---|---|
| Federated identity (default) | A cross-tenant federated credential. No secret is stored on our side. | Remove the role assignment in your own tenant. |
| Shared access signature | A token you generate and give us. | Rotate the storage key, or let the token expire. |
For your own OneLake, access runs through your Fabric workspace and is governed by your Fabric permissions.
Where an AI Readiness result goes when you have declared your own storage
This is the control that most often goes unstated, so it is worth stating plainly. When you have declared your own storage, BI Pixie does not write a finished AI Readiness assessment into BI Pixie storage. Where it goes instead depends on which storage you chose, and the two answers are genuinely different.
On your own OneLake, BI Pixie writes the full result into your lakehouse, in the same place as your telemetry, and reads it back from there whenever you open it. The only lasting copy is the one in your own Fabric capacity, under your own Fabric permissions. The assessments you had made BEFORE you chose your own OneLake are moved there too: BI Pixie copies each one into your lakehouse and then deletes its own, so the same sentence is true of your whole history rather than only of the part made since. Your raw events are the one thing that is not moved, because they already have a copy in your lakehouse from the moment you switch.
On your own Azure storage, BI Pixie writes the result nowhere. We do not write assessment results into your ADLS Gen2 account, so you see the full result when the assessment finishes and there is nothing to reopen afterwards. If keeping your assessments is what you want, your own OneLake is the option that does it.
In both cases we record the score and the number of findings, and never the findings themselves. The one exception is the handover described in Where each kind of data lives above: the job record that carries a finished result back to you is deleted within one day, and what remains after that holds the score and the counts.
If you have declared your own storage and BI Pixie cannot reach it at that moment, the assessment is still not written to ours. It is skipped, and you can run it again.
The honest boundary: scoring a semantic model means reading its definition through BI Pixie’s service, so the definition is processed by us even where the result is never stored with us.
BI Pixie keeps no copy of a semantic model that you change with AI Readiness. If you ask BI Pixie support for help, support can turn on a copy for your account: BI Pixie then keeps the semantic model definition from before and after each AI Readiness change for 30 days, in the region assigned to the account, so that support can see what changed. When you have declared your own storage, BI Pixie keeps no copy, even when support has turned the copy on.
Sub-Processors
Sub-processors are third parties that process customer data through BI Pixie. The list below applies to the BI Pixie Cloud and BI Pixie Workload deployment models. For BI Pixie on Azure and BI Pixie on Power Platform deployments, we have no access to customer data and therefore engage no sub-processors on the customer’s behalf. Your own sub-processor relationships govern.
Microsoft Azure and Stripe are companies we engage. OpenAI and Anthropic are AI providers you can connect yourself, and BI Pixie calls neither of them until an administrator on your account has connected one.
| Sub-Processor | Purpose | Data involved | Applies to |
|---|---|---|---|
| Microsoft Azure | Infrastructure hosting, storage, identity, monitoring | All customer data in scope | BI Pixie Cloud, BI Pixie Workload |
| Stripe | Payment processing | Billing contact and payment metadata only; card details are never stored on BI Pixie servers | BI Pixie Cloud, BI Pixie Workload (Stripe-billed plans only) |
| OpenAI | Drafting AI Readiness text and reviewing AI benchmark answers, for the semantic models you select | Semantic model definition content, plus the specific business data values listed in Privacy §3.7. No telemetry event records and no end-user identifiers | BI Pixie Cloud, BI Pixie Workload, and only while you have connected your own OpenAI key |
| Anthropic | Drafting AI Readiness text and reviewing AI benchmark answers, for the semantic models you select, and answering the questions of a benchmark of Claude run in BI Pixie | Semantic model definition content, plus the specific business data values listed in Privacy §3.7, and, in a benchmark of Claude, the rows Claude’s queries return, with any text that looks like an email address withheld. No telemetry event records and no end-user identifiers | BI Pixie Cloud, BI Pixie Workload, and only while you have connected your own Anthropic key |
OpenAI and Anthropic are engaged by you, not by us. You decide whether to connect either company, you hold the account with it, you supply the credential, and your own agreement with that company governs what it does with the request. They are listed here so that your reviewers can see every third party that receives your content through BI Pixie, whoever engaged it. Removing the connection on the Account page stops every such call.
A benchmark of Claude run in BI Pixie follows the same rule. Claude answers it only under an Anthropic key saved on your account, BI Pixie never pays Anthropic for those answers, and BI Pixie does not start the benchmark when no such key is saved.
The BI Pixie connector in Claude. A person on your account can add the BI Pixie connector to their own Claude in claude.ai. BI Pixie then runs read-only queries as that person, with their own permissions and row-level security, from a BI Pixie service in your assigned region (mcp.bipixie.com in the United States, mcp-eu.bipixie.com in Europe). BI Pixie holds the rows in memory only while it passes them to that person’s Claude, and stores and logs none of them. BI Pixie replaces any text in the rows that looks like an email address with “(email address withheld)” before Claude receives them, and Anthropic receives them under that person’s own Claude account. BI Pixie engages no sub-processor for the connector. For each query, BI Pixie keeps the name and version of the AI app that made it and the time, with no person named, for 180 days, and it keeps the date each person’s Claude first used the connector on that person’s member record. An administrator on your account can turn off Claude’s queries of your semantic models for everyone. Privacy §3.6 describes the connector in full.
Two further AI provider options are not listed above, because neither sends your content to a company outside Microsoft. Microsoft Foundry runs in your own Azure subscription, and the BI Pixie data agent runs on your own Microsoft Fabric capacity.
The authoritative sub-processor list and the customer-data scope it applies to are maintained in our Privacy Policy §7, and Privacy §3.7 states in full what BI Pixie sends to a connected AI provider and what it never sends. We will provide reasonable advance notice of any material changes to this list.
Audits and Assessments
We maintain an internal security-assessment program covering dependency scanning, static analysis (SAST), Azure posture review, dynamic scanning (DAST), API security, multi-tenant isolation, and GDPR controls. We run an automated audit over the whole codebase every night. We are alerted to any failure, and the alert stays open until a nightly run passes:
- Dependency Audit:
pip-auditon all backend Python services andnpm auditon the customer portal and Fabric workload frontend, failing on high-severity findings. A change to a dependency is also audited before it can merge. - Static Analysis:
Semgrepon application code (Python and TypeScript, with OWASP Top 10 + secrets rule packs) andCheckovon Bicep infrastructure templates. Baselines are triaged with documented suppressions for each accepted-risk finding.
Every change is also checked for committed credentials before it can merge.
For the BI Pixie Workload variant, our compliance posture is published in detail in the Microsoft Fabric Workload Vendor Attestation per Microsoft’s publishing requirements.
DataChant has not engaged a third-party auditor for SOC 2 Type II at this time and will reassess as customer requirements warrant. Under a non-disclosure agreement, we can share additional artifacts from the internal assessment program with prospective enterprise customers on request. Email support@bipixie.com.
Vulnerability Disclosure
If you believe you have discovered a security vulnerability in BI Pixie, please report it to support@bipixie.com. We will acknowledge receipt within two business days. Please do not publicly disclose the issue until we have had a reasonable opportunity to investigate and remediate.
We do not currently operate a paid bug-bounty program. We do gratefully acknowledge responsible disclosure on request.
Contact
- Security and procurement questions: support@bipixie.com
- Privacy inquiries: support@bipixie.com (per Privacy Policy §15)
- General support: support@bipixie.com
BI Pixie is operated by DataChant Consulting LLC, an Illinois limited liability company. “BI Pixie” is the company’s registered assumed name, filed with the Illinois Secretary of State on 2026-09-02.