AI Learning Management System

Two principles matter: data minimization and provider control. OpenEduCat lets you self-host the LMS and route AI calls to a model endpoint you choose — including an on-prem Llama, Mistral, or Qwen GGUF where nothing leaves your network. When you do use a hosted model, the request payload is configurable so directory identifiers (student IDs, names, emails, IEP flags) can be redacted or pseudonymized before sending. This aligns with the US Department of Education's 2023 report 'Artificial Intelligence and the Future of Teaching and Learning,' which emphasizes human-in-the-loop oversight, tight scoping of what student data feeds AI systems, and clear lines of accountability when AI-assisted decisions affect a student's record. Self-hosted EU deployments keep data inside your chosen region for GDPR residency, and FERPA-aligned audit logs record every AI invocation — prompt, response, model, timestamp, user — for disclosure review or freedom-of-information requests.

Only if you explicitly configure them to be. The default Community Edition ships with model endpoints disabled; you pick a provider — OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, Google Vertex AI, a self-hosted Ollama or vLLM endpoint, or a local GGUF model running on a single GPU box — and we send requests to that endpoint over your chosen credential. We never proxy through OpenEduCat servers, and we never relay student data to a vendor analytics pipeline. For districts and ministries that require zero external traffic, the on-prem model path keeps every inference inside your firewall, with offline operation supported for environments that cannot guarantee outbound connectivity.

Yes — BYOM is the default posture, not a paid upgrade. The AI features in openeducat_lms talk to an abstract Provider interface, so swapping models is a configuration change, not a re-platform. Supported endpoints include OpenAI-compatible APIs (which covers OpenAI, Azure OpenAI, vLLM, Ollama, LM Studio, and most open-source inference servers), Anthropic's Messages API, AWS Bedrock, Google Vertex AI, and any HuggingFace TGI server. Embeddings work the same way — point at OpenAI, Cohere, Voyage, or a local bge, nomic, or e5 model. Each AI feature can use a different model: a small local model for low-stakes recommendations and a frontier model only for the cases that warrant it. This avoids the lock-in risk of buying an AI feature welded to one vendor's stack, which several institutional buyers have already had to unwind after their first-pick provider changed pricing.

Three layers. First, rubric grading is deterministic against teacher-authored criteria with required evidence quotation from the student response, which reduces vibes-grading and forces the model to point at what it's scoring. Second, every AI grade and tutor exchange is logged with the prompt, model version, temperature, and parameters used, so periodic fairness audits are possible across demographic slices (with appropriate consent and IRB-style review where required). Third, our docs include a fairness-audit notebook that lets your institutional research team compare grade distributions, tutor-engagement rates, and intervention flags across cohorts to catch drift early. EDUCAUSE's 2024 AI landscape work has repeatedly flagged that institutions lack visibility into vendor AI bias — keeping logs in your own database is the only way to actually do the audit, and we make the data accessible rather than hiding it behind a vendor dashboard.

Yes — opt-out is a first-class feature, not an afterthought. AI-tutor, AI-grading, content recommendation, and engagement analytics can each be toggled per student or per cohort independently, so a parent can decline AI tutoring while still benefiting from caption generation. A guardian-facing consent screen surfaces during onboarding for K-12 deployments, with re-consent prompts at the start of each academic year. When a student opts out, their submissions route to the standard manual review path, are excluded from any model-training-related telemetry, and the opt-out is recorded as part of the student record. This matches the consent posture recommended by the US Department of Education's 2023 AI guidance and the emerging state AI policies in places like California, Virginia, and Tennessee.

Three lock-in axes to evaluate before signing any AI LMS contract: the LMS platform itself, the AI model layer, and your underlying data. OpenEduCat addresses all three intentionally. The LMS is LGPLv3 open-source, so the code is yours to fork, audit, or self-host indefinitely — there is no scenario where a vendor decision strands your institution. The AI layer is provider-agnostic via BYOM, so switching from OpenAI to Anthropic to an on-prem Llama is a config change, not a migration project. Your data lives in your Postgres instance, with standard SQL exports, a publicly documented schema, and stable model identifiers, so leaving — if you ever choose to — is a database dump, not a vendor extraction project. Compare that to a closed SaaS where leaving means recreating courses, gradebooks, and AI history from scratch in the next vendor.

Three components to budget. The LMS license is either free Community or $19/user/month Enterprise for support, SLA, and proprietary modules. Infrastructure is your existing servers, a managed cloud, or a partner-hosted deployment — most mid-size deployments run on a single Postgres + app VM with horizontal scaling when needed. AI inference is pass-through to the provider you pick: a 5,000-student deployment using gpt-4o-mini class models for tutoring and a local embedding model typically lands well under $1/student/month in AI inference, sometimes much lower depending on usage patterns. Self-hosted models trade inference dollars for GPU CapEx, which usually makes sense above a certain enrollment scale or in environments with strict data-locality requirements. We publish a sample TCO worksheet so procurement teams can model it against your specific enrollment, model mix, and infrastructure choices instead of guessing from a brochure.