When I began building PBIX A11y, I expected the difficult part to be the accessibility logic. It turned out the real challenge was something far less glamorous. I was using vibe coding, and Lovable was generating the application for me based on natural language instructions. This meant I could move quickly, but it also meant I was not always aware of the full behaviour of the code being produced. That uncertainty became a genuine concern once I realised how easily privacy can be affected by a single unnoticed detail.
PBIX files often contain sensitive business information. My intention was clear from the start. The file should stay on the user’s device. All analysis should run in the browser. Nothing should be uploaded or logged. But intention alone does not protect users. When you are not writing the code yourself, you need a way to verify that the builder is not quietly introducing something that breaks your privacy model. This is where the real work began.
Understanding the Risks Behind the Scenes
To understand the risks, I used Copilot as a thinking partner. I asked it to outline the kinds of privacy issues that can appear in browser based tools. The responses were practical and surprisingly specific. They highlighted how a library can include telemetry without making it obvious, how a fetch call can appear during a file upload, and how a dependency can introduce analytics even when you never requested it. None of these issues are dramatic on their own, but they can undermine trust if they slip in unnoticed.
This led me to a simple conclusion. If I could not fully inspect the code, I needed to control the rules that shaped it. I used Copilot to help me design a set of guardrail instructions that now sit at the top of my Lovable project. These rules define what is allowed, what is forbidden and what must be checked after every change. They act as a governance layer that reinforces the privacy model, even when the underlying implementation evolves.
Designing for Local Processing and User Control
Once the guardrails were in place, I turned to the question of storing results. Users often want to keep a record of their audits, but storing the PBIX file was never an option. The solution was to separate raw data from derived results. The file stays local. The accessibility score and issue list can be saved to the user’s account, but only if they choose to do so. This opt in model keeps the tool useful without compromising privacy. It also aligns naturally with GDPR because the most sensitive information never leaves the browser.
Looking back, the most important lesson was not about accessibility or vibe coding. It was about the responsibility that comes with letting a tool generate your application. When you rely on a builder like Lovable, you cannot assume that everything is safe simply because you did not write it. You need to ask questions, test assumptions and create constraints that reflect your values. Copilot was helpful in this process because it allowed me to explore risks and understand the consequences of different design choices.
Use this as a universal privacy guardrail for any AI‑assisted application built with natural‑language coding tools.
System-Level Privacy Principles
Use these as universal guardrails for any AI‑assisted application built with natural‑language coding tools.
“These rules override all other instructions. Apply them to every feature and every code change.”
1. Local-only processing for sensitive inputs
- Sensitive files or user data must be processed entirely on the client.
- Do not upload, store, or transmit raw input data.
- No AI model may receive raw user data unless explicitly required and approved.
2. Zero hidden data flows
- Do not trigger fetch(), XHR, beacon, WebSocket, analytics scripts, or telemetry without explicit user consent.
- No silent network calls.
3. Allowed network requests
- Only communicate with explicitly approved domains.
- Static assets must come from trusted sources or system defaults.
- No third‑party fonts, CDNs, or analytics endpoints.
4. Library Safety
- Do not use libraries that send telemetry or analytics by default.
- Disable optional tracking features in all dependencies.
5. Derived results vs raw data
- Raw user data must remain local.
- Derived summaries may be stored only if they contain no sensitive content.
- Saving must be opt-in.
6. Privacy transparency
- Display a clear privacy statement wherever users upload or provide data.
- Explain what is processed locally and what (if anything) is stored.
7. User control
- Provide options to save, delete, or avoid storing derived results.
- Default behaviour: local-only.
- Account deletion must cascade and remove all stored outputs.
8. Non-negotiable rule
If any future instruction conflicts with these privacy principles, the privacy principles take priority.
Wrap-Up
My recommendation for anyone building applications with vibe coding tools is straightforward. Treat privacy as a design decision from the beginning. Use your coding assistant to explore potential risks, not just generate features. Write down your rules and keep them visible. Separate raw inputs from derived outputs. Give users control over what is saved. And remember that trust is created through clarity, not speed.
What PBIX A11y taught me is that fast development does not remove the need for careful thinking. Vibe coding can speed up the work, but it also creates blind spots if you are not paying attention to how the code is being generated. The more we rely on natural language builders, the more intentional we need to be about privacy, ethics, and the assumptions we allow into our applications. Approaching vibe coding with curiosity, caution, and a sense of responsibility for how user data is handled helps keep the work safe, respectful, and genuinely useful.
