Our core commitment: AI can assist the work. It does not replace human judgment, authorize a new use of your information, or take accountability for what we deliver.
1. Scope and operating principles
This policy describes Programz’s approach to data in software development engagements and AI-assisted work. It complements our Privacy Policy. Your signed project agreement, security requirements, and any data processing agreement establish the specific obligations for your engagement and control if there is a conflict.
Our approach is based on purpose limitation, data minimization, confidentiality, authorized access, and human verification. We use the information needed for agreed work, choose lower-risk alternatives where practical, and establish data boundaries before giving a tool access.
2. The information a project may involve
The exact information depends on the engagement. We discuss what is needed and how it will be handled rather than assuming access to all your systems.
| Information | Typical purpose | Default approach |
|---|---|---|
| Business requirements and documentation | Understand workflows and define the solution. | Share with authorized project personnel and approved tools only. |
| Source code and technical configurations | Develop, review, integrate, and maintain software. | Use access-controlled repositories and agreed development environments. |
| Test data | Verify functionality, security, and performance. | Prefer synthetic or de-identified data; check the risk of re-identification. |
| Production or personal data | Only where needed for an authorized task. | Agree on access, safeguards, and any required processing terms first. |
| Credentials, keys, and secrets | Authorized access or deployment. | Use approved secret-management channels, not prompts, source code, or inquiry emails. |
Regulated or sensitive information, such as health records, payment data, or government identifiers, requires an explicit assessment and suitable contractual and technical controls before access. We do not assume an ordinary development agreement authorizes handling those categories.
3. Boundaries for AI-assisted development
Appropriate assistance, not unrestricted access
AI may assist with coding, technical exploration, documentation, or test generation when useful and permitted. We evaluate the tool, the task, the information involved, and the client’s requirements. We do not send confidential client information, proprietary source code, personal data, or secrets to an AI service without authorization and suitable safeguards.
Training and secondary use
We do not use client materials to train our own general-purpose AI models or contribute them to public training datasets. For an approved third-party AI tool, we assess and agree on its data-use terms and relevant settings, including available training opt-outs, retention, access, and processing locations. We do not treat a “no training” setting as proof of zero retention or zero provider access.
If a provider’s data practices do not meet the project requirements, we use an alternative workflow. Any project-specific model training or fine-tuning using client data requires explicit written authorization, a defined purpose, and agreed rights and safeguards.
Minimize what enters a prompt
Where practical, we use synthetic examples, redact unnecessary details, isolate the relevant code, or work in an approved private environment. Credentials and secrets are never appropriate prompt content. AI tools do not receive permission to publish client materials or make unrelated use of them.
No unapproved consequential decisions
Development assistants are not authorized to independently make legal, employment, financial, or other consequential decisions about people. If your product includes AI-driven features, we separately scope its behavior, evaluation, human oversight, and applicable requirements.
4. Human quality gates and accountability
AI-generated output is a proposal, not a finished deliverable. Our engineers review architecture and code, evaluate dependencies, and take responsibility for accepting or rejecting the output within the agreed work.
- Human-performed security review: in-depth assessment of the agreed scope, including relevant access controls, data flows, dependencies, and implementation risks.
- Human-performed testing: hands-on checks of user workflows, edge cases, and real-world behavior, supported by automated tests where appropriate.
- Performance and maintainability: evaluation against the project’s expected workloads and long-term needs.
- Deployment review: environment configuration, access boundaries, release steps, and handover documentation appropriate to the engagement.
Testing and audits reduce risk but cannot prove the absence of every defect or vulnerability. Findings, acceptance criteria, unresolved risks, and remediation priorities are addressed through the project’s agreed review and release process. We do not present generated code as independently verified simply because a tool produced it.
5. Access, collaborators, and service providers
Access should be limited to authorized people and tools that need it for the project. We use confidentiality obligations, role-appropriate permissions, and approved repositories and communication channels. Access is reviewed and revoked when it is no longer required.
Relevant hosting, repository, cloud, collaboration, and AI providers are considered in the project’s data-handling plan. Where we act as a processor, subprocessors and their authorization are handled under the applicable data processing agreement. If processing crosses borders, we address required transfer safeguards before the affected processing begins.
6. Security and incident handling
Safeguards are chosen based on the sensitivity of the data and the project’s requirements. They may include encrypted transport, appropriate encryption at rest, multifactor authentication, secret management, environment separation, dependency checks, and security logging.
If we become aware of unauthorized access to client data in our care, we investigate, contain the issue, preserve relevant evidence, and notify the client in accordance with the project agreement and applicable law. We support required remediation and notifications within the agreed responsibilities. Specific incident contacts and notice timeframes belong in the project agreement or data processing agreement.
7. Retention, return, deletion, and handover
We agree on where project data is stored, who controls it, and what happens when the engagement ends. Depending on the agreement, handover may include repositories, deployment instructions, configuration documentation, review findings, and transfer of appropriate administrative access.
Client data is returned or deleted according to the agreement, subject to legal retention obligations and agreed backup cycles. Necessary contract and accounting records may be retained separately, as described in our Privacy Policy. Provider logs, backups, or retained copies are considered in the plan; we do not promise immediate erasure from every backup where that is technically or legally unavailable.
8. Ownership, licensing, and reuse
You retain your rights in the materials you provide. Ownership and licenses for new deliverables, pre-existing tools, and reusable components are set out in the project agreement. Open-source software and third-party services remain subject to their respective terms.
We review AI-assisted output for quality and relevant provenance or licensing concerns where identifiable. AI generation alone is not a guarantee of originality or exclusive intellectual property rights. We do not publish your confidential code, identify your project in a case study, or reuse your private data for unrelated work without permission.
9. Your role in a safe engagement
Clients are responsible for having authority to provide their materials and instructions, identifying applicable regulatory or contractual restrictions, and sharing any required security standards before processing starts. Please disclose data categories and access limitations rather than sending an unrestricted database or credentials in an inquiry.
We work together to define authorized uses, approved tools, responsible contacts, acceptance criteria, and the division of operational responsibilities after launch. If requirements change, we review the impact before expanding access or introducing new data flows.
10. Questions, project requirements, and updates
If you have a restricted environment, a no-AI requirement, a data residency requirement, or a specific compliance obligation, tell us during scoping so we can determine a suitable approach. No project is deemed compliant with a particular framework solely because it follows this general policy.
We update this policy as our approach evolves and revise the effective date. Updates do not override an existing signed agreement without the agreed change process.
Data and AI contact: Programz, Wyoming, United States
Email: hello@programz.net
Related policies: Privacy Policy and Terms & Conditions.