How Pionix uses AI tools
// Answers to common questions from our partners
Pionix uses AI-assisted development tools across analysis, code generation, review, testing and documentation. We do this openly, under contractual safeguards, and with our engineers responsible for every result. This page summarizes how it works and what it means for your code and your project.
Is our code kept confidential when AI tools touch it?
Yes. We only use AI tools under enterprise or business-tier agreements that contractually require the provider to treat all inputs as confidential. Using these tools on your code is not a disclosure to a third party under our confidentiality obligations, and where personal data is involved, a GDPR data processing agreement and safeguards for third-country transfers are in place.
Is our data used to train AI models?
No. The provider agreements we work under contractually guarantee that neither inputs nor outputs are used to train the provider’s models. Your code, materials and information stay yours. We also limit ourselves to a small set of established providers, currently OpenAI and Anthropic, rather than experimenting with arbitrary models on customer code.
Who is responsible for AI-generated code?
Pionix is, fully and unchanged. Every result is reviewed by our engineers before it reaches you, and the same standard of skill and care, the same IP provisions and the same liability terms apply regardless of the tools used. Internally the rule is simple: the engineer owns the code they commit, AI-generated or not. If they cannot explain a change, it is not ready.
Can we restrict or exclude AI use on our project?
Yes. On request we disclose the categories of AI tools we use, and you can restrict or exclude specific tools, or their use on specific repositories or materials, in your Individual Order. Restrictions affect delivery speed and cost, so we recommend discussing the trade-off with your Pionix contact first.
Does AI make the software better or riskier?
Better, because we spend the saved effort where it counts. Implementation time no longer forces architecture compromises, so we invest more in specification and design up front, where our EVerest and charging-domain expertise matters most. Human review shifts from reading every line to judging architecture, interfaces and domain correctness, and authors must prove how a change was tested before it is merged.
Testing gets more investment, not less: we are expanding automated unit and integration coverage in EVerest, plus software-in-the-loop conformance fixtures (such as automated OCPP compliance testing) and hardware-in-the-loop rigs that exercise real charging hardware. Review depth scales with risk: a change to charging session logic gets far deeper scrutiny than a documentation fix.
Questions about your project specifically?
Talk to your Pionix contact, or write to us and we will walk you through the clauses in your agreement.