Q: What are Copilot’s limitations?
A: Copilot operates on schema metadata and does not have runtime access to row-level data. Context is scoped to the current project — cross-project scope is planned but not yet live. Very large models may exceed the context window, in which case the AI works with the most relevant portion. The AI proposes changes; it does not execute them without explicit user action.
Q: What are Copilot’s potential biases, and how do you mitigate them?
A: Potential biases inherited from foundation models are documented in model provider cards. Within SqlDBM’s domain — data modeling and governance — the AI is grounded in the customer’s own schema and governance rules, which narrows general-purpose biases significantly. Three additional mitigations are in place: pre-prompts ground every interaction in documented standards; role-based responses match output to the user’s context; and every AI-generated change is proposed rather than applied, requiring human review before commit.
Q: What are Copilot’s accuracy metrics?
A: Internal accuracy is tracked on representative data modeling tasks, including reverse engineering quality, description generation fidelity, and governance flag accuracy. Because Copilot operates against the customer’s grounded context, accuracy on data modeling work is significantly higher than general-purpose AI. Aggregate benchmarks and task-level metrics are available under NDA.
Q: How does Copilot protect against making changes we don’t want?
A: Three layers. First, every AI-generated change is proposed — the user reviews and approves before any change lands in the model. Second, pre-prompts let the organization define standing instructions that constrain what the AI does across every prompt. Third, per-user permissions let admins control who has AI access at all. The AI does not act autonomously.